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 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
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
>
>
>