Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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
> 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?

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


pgsql-hackers by date

Next:From: scott.marloweDate: 2002-08-27 15:51:10
Previous:From: scott.marloweDate: 2002-08-27 15:40:31
Subject: Re: Default privileges for new databases (was Re: Can't

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group