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>>>