Re: heap_delete, heap_mark4update must reset t_ctid

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vadim Mikheev <vmikheev(at)sectorbase(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: heap_delete, heap_mark4update must reset t_ctid
Date: 2002-08-27 15:50:06
Message-ID: 200208271550.g7RFo8U27108@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Has this been fixed? I think we did.

---------------------------------------------------------------------------

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
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message scott.marlowe 2002-08-27 15:51:10 Re: REINDEX ALL and CLUSTER ALL
Previous Message scott.marlowe 2002-08-27 15:40:31 Re: Default privileges for new databases (was Re: Can't