FAQ
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

Search Discussions

  • Barry Lind at Jul 19, 2002 at 5:01 pm
    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
    >
    >
    >
  • Bruce Momjian at Aug 27, 2002 at 3:50 pm
    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
  • Tom Lane at Aug 27, 2002 at 3:53 pm

    Bruce Momjian writes:
    Has this been fixed? I think we did.
    Yes.

    regards, tom lane
  • Bruce Momjian at Aug 27, 2002 at 3:54 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 18, '02 at 6:01p
activeAug 27, '02 at 3:54p
posts5
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase