Horton
Menu

Thread

  1. heap_delete, heap_mark4update must reset t_ctid

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-07-18T18:01:42Z

    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

  2. Re: heap_delete, heap_mark4update must reset t_ctid

    Barry Lind <barry@xythos.com> — 2002-07-19T17:03:04Z

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

  3. Re: heap_delete, heap_mark4update must reset t_ctid

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-27T15:50:06Z

    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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

  4. Re: heap_delete, heap_mark4update must reset t_ctid

    Tom Lane <tgl@sss.pgh.pa.us> — 2002-08-27T15:53:49Z

    Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Has this been fixed?  I think we did.

Yes.

			regards, tom lane

  5. Re: heap_delete, heap_mark4update must reset t_ctid

    Bruce Momjian <pgman@candle.pha.pa.us> — 2002-08-27T15:54:50Z

    As you can see, there is a lot of cruft left in my mailbox, but there
are some items that we left behind that may be fixable before 7.3.

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

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Has this been fixed?  I think we did.
> 
> Yes.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

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