There are so many mails for me to follow about this issue.
For example,what's the conclusion about the following ?
Please teach me.
> -----Original Message-----
> From: owner-pgsql-hackers@postgreSQL.org
> [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
>
>
> BTW, I don't see any really good reason to keep the out-of-line values
> in a separate physical file (relation) as Jan originally proposed.
> Why not keep them in the same file, but mark them as being something
> different than a normal tuple? Sequential scans would have to know to
> skip over them (big deal), and VACUUM would have to handle them
> properly, but I think VACUUM is going to have to have special code to
> support this feature no matter what. If we do make them a new primitive
> kind-of-a-tuple on disk, we could sidestep the problem of marking all
> the out-of-line values associated with a tuple when the tuple is
> outdated by a transaction. The out-of-line values wouldn't have
> transaction IDs in them at all; they'd just be labeled with the CTID
What is wong if out-of-line values have their own XIDs ?
If an out-of-line is newer than corresponding row in "primary" table
it's bad but could it occur ?
Because (rowid) of "secondary" table references "primary" table(oid)
on delete cascade,XID_MAXs of them would be synchronized.
Why is CTID needed ? Is it necessary to know "primary" tuples from
out-of-lines values ?
> and/or OID of the primary tuple they belong to. VACUUM would consult
> that tuple to determine whether to keep or discard an out-of-line value.
>
What is wrong with separate VACUUM ?
VACUUM never changes OIDs and XIDs(after MVCC).
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp