I have been looking at an example of the "no one parent tuple found"
VACUUM error provided by Mario Weilguni. It appears to me that VACUUM
is getting confused by a tuple that looks like so in pg_filedump:
Item 4 -- Length: 249 Offset: 31616 (0x7b80) Flags: USED OID: 0 CID: min(240) max(18) XID: min(5691267)
max(6484551)Block Id: 1 linp Index: 1 Attributes: 38 Size: 40 infomask: 0x3503
(HASNULL|HASVARLENA|XMIN_COMMITTED|XMAX_COMMITTED|MARKED_FOR_UPDATE|UPDATED)
Notice that the t_ctid field is not pointing to this tuple, but to a
different item on the same page (which in fact is an unused item).
This causes VACUUM to believe that the tuple is part of an update chain.
But in point of fact it is not part of a chain (indeed there are *no*
chains in the test relation, thus leading to the observed failure).
As near as I can tell, the sequence of events was:
1. this row was updated by a transaction that stored the updated version
in lineindex 1, but later aborted. t_ctid is left pointing to linp 1.
2. Some other transaction came along, marked the row FOR UPDATE, and
committed (with no actual update).
So we now have XMAX_COMMITTED and t_ctid != t_self, which looks way too
much like a tuple that's been updated, when in fact it is the latest
good version of its row.
I think an appropriate fix would be to reset t_ctid to equal t_self
whenever we clear XMAX_INVALID, which in practice means heap_delete and
heap_mark4update need to do this. (heap_update also clears
XMAX_INVALID, but of course it's setting t_ctid to point to the updated
tuple.)
Comments?
regards, tom lane