Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Zdenek Kotala wrote:
>> If I'm thinking more, it is not probably CATALOG_VERSION_NO as well.
>> Because toast table is created on demand. It is not in BKI.
> It's not catversion in the sense that there's no catalog change, but it
> certainly requires a catversion bump due to internal changes.
> Otherwise, developers who have working data directories today will see
> weird errors when they update to a CVS version after this commit.
Yes. The real purpose of catversion is to keep developers from wasting
time using an incompatible data directory.
As far as the point at hand goes: the original discussion about this
assumed that we'd add at least one "identity" column to toast tables,
which would allow the t_natts of a toast tuple to effectively serve
as a version number. So that fixes the problem of how to know what
you are looking at. What it doesn't solve is the problem of how to
know what range of index values to search for in a partial-fetch
operation. If you just scan what would be the expected range of
converted chunk positions, you might miss all the old-format entries.
Anyone have a clue on that?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
