> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > AFAIR t_ctid isn't logged in WAL.
>
> After looking at the heap_update code I think you are right. Doesn't
> that render the field completely useless/unreliable?
Redo runs with no concurrent backends. New backends invoked
after a redo operation don't need(see) the existent t_ctid values.
PostgreSQL before MVCC didn't need the t_ctid.
>
> In the simple heap_update case I think that heap_xlog_update could
> easily set the old tuple's t_ctid field correctly. Not sure how
> it works when VACUUM is moving tuple chains around, however.
>
> Another thing I am currently looking at is that I do not believe VACUUM
> handles tuple chain moves correctly. It only enters the chain-moving
> logic if it finds a tuple that is in the *middle* of an update chain,
> ie, both the prior and next tuples still exist. ^^^^^
Isn't it *either* not *both* ?
Anyway I agree with you at the point that the tuple chain-moving
is too complex. It's one of the main reason why I prefer the new
VACUUM.
regards,
Hiroshi Inoue