Re: heap_delete, heap_mark4update must reset t_ctid

Tom,

When/if you have a patch for this, I would like to test it.  I still
have a copy of a database showing the same problem that I would like to
test this on when it is ready.

thanks,
--Barry

Tom Lane wrote:
>I have been looking at an example of the "no one parent tuple found">VACUUM error provided by Mario Weilguni.  It
appearsto 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
pointingto this tuple, but to a>different item on the same page (which in fact is an unused item).>This causes VACUUM
tobelieve 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*>chainsin 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_ctidis left pointing to linp 1.>>2. Some other transaction came along, marked the row FOR UPDATE, and>committed (with
noactual update).>>So we now have XMAX_COMMITTED and t_ctid != t_self, which looks way too>much like a tuple that's
beenupdated, when in fact it is the latest>good version of its row.>>I think an appropriate fix would be to reset
t_ctidto equal t_self>whenever we clear XMAX_INVALID, which in practice means heap_delete and>heap_mark4update need to
dothis.  (heap_update also clears>XMAX_INVALID, but of course it's setting t_ctid to point to the
updated>tuple.)>>Comments?>>    regards, tom lane>>---------------------------(end of
broadcast)--------------------------->TIP6: Have you searched our list archives?>>http://archives.postgresql.org>>>