RE: [HACKERS] LONG

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