Re: vacuum full fails: Parent tuple was not found[7.2] - Mailing list pgsql-sql

From Tom Lane
Subject Re: vacuum full fails: Parent tuple was not found[7.2]
Date
Msg-id 26285.1017769235@sss.pgh.pa.us
Whole thread Raw
In response to vacuum full fails: Parent tuple was not found[7.2]  (george young <gry@ll.mit.edu>)
List pgsql-sql
george young <gry@ll.mit.edu> writes:
> [Postgres 7.2, SuSE Linux 7.3 (2.4.10), Pentium-III, gcc-3.0.4]
> vacuum full fails on pg_class:

>   VACUUM FULL VERBOSE ANALYZE pg_class;
>   NOTICE:  --Relation pg_class--
>   NOTICE:  Pages 147: Changed 0, reaped 134, Empty 0, New 0; Tup 2559: Vac 0, Keep/VTL 666/222,   UnUsed 7051, MinLen
116,MaxLen 176; Re-using: Free/Avail. Space 833148/831052; EndEmpty/Avail.   Pages 0/116.
 
>    CPU 0.00s/0.00u sec elapsed 0.00 sec.
>   NOTICE:  Index pg_class_oid_index: Pages 45; Tuples 2559: Deleted 0.
>    CPU 0.02s/0.00u sec elapsed 0.05 sec.
>   NOTICE:  Index pg_class_relname_index: Pages 149; Tuples 2559: Deleted 0.
>    CPU 0.04s/0.00u sec elapsed 0.11 sec.
>   ERROR:  Parent tuple was not found

> What does this mean, and how can I fix it?

This looks like a bug in VACUUM FULL's handling of chains of updated
tuples (ie, a series of updates of the same row that might all still
be visible to some open transaction(s)).  I am guessing that somewhere
in the background you have a backend sitting idle with an open BEGIN
block.  Closing that transaction will probably make the error disappear.

I have long suspected that the VACUUM chain logic still contains some
corner-case mistakes, but it's very difficult to come by test cases.
I am itching to look at your case with a debugger ... but unless your
installed postmaster was already compiled with debug symbols, there's
probably no hope of learning anything here.  Reinstalling a
debug-enabled executable would entail closing that open transaction,
which will make the symptom disappear.

If by chance you do have debug symbols in your installation, then
please DON'T close that open transaction.  Let's talk ...
        regards, tom lane


pgsql-sql by date:

Previous
From: Tom Lane
Date:
Subject: Re: Database Locations
Next
From: "David Stanaway"
Date:
Subject: Re: resetting sequence