Thread: pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away
pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away
From
tgl@postgresql.org (Tom Lane)
Date:
Log Message:
-----------
Fix aboriginal mistake in lazy VACUUM's code for truncating away
no-longer-needed pages at the end of a table. We thought we could throw away
pages containing HEAPTUPLE_DEAD tuples; but this is not so, because such
tuples very likely have index entries pointing at them, and we wouldn't have
removed the index entries. The problem only emerges in a somewhat unlikely
race condition: the dead tuples have to have been inserted by a transaction
that later aborted, and this has to have happened between VACUUM's initial
scan of the page and then rechecking it for empty in count_nondeletable_pages.
But that timespan will include an index-cleaning pass, so it's not all that
hard to hit. This seems to explain a couple of previously unsolved bug
reports.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/commands:
vacuumlazy.c (r1.81.2.2 -> r1.81.2.3)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c?r1=1.81.2.2&r2=1.81.2.3)
On 9/15/2007 10:37 PM, Tom Lane wrote: > Log Message: > ----------- > Fix aboriginal mistake in lazy VACUUM's code for truncating away > no-longer-needed pages at the end of a table. We thought we could throw away > pages containing HEAPTUPLE_DEAD tuples; but this is not so, because such > tuples very likely have index entries pointing at them, and we wouldn't have > removed the index entries. The problem only emerges in a somewhat unlikely > race condition: the dead tuples have to have been inserted by a transaction > that later aborted, and this has to have happened between VACUUM's initial > scan of the page and then rechecking it for empty in count_nondeletable_pages. > But that timespan will include an index-cleaning pass, so it's not all that > hard to hit. This seems to explain a couple of previously unsolved bug > reports. You mean symptoms like multiple index tuples pointing to the same heap tuple, thus presenting the same heap tuple twice during an index scan, don't you? Jan > > Tags: > ---- > REL8_2_STABLE > > Modified Files: > -------------- > pgsql/src/backend/commands: > vacuumlazy.c (r1.81.2.2 -> r1.81.2.3) > (http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/commands/vacuumlazy.c?r1=1.81.2.2&r2=1.81.2.3) > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
Jan Wieck <JanWieck@Yahoo.com> writes:
> On 9/15/2007 10:37 PM, Tom Lane wrote:
>> Fix aboriginal mistake in lazy VACUUM's code for truncating away
>> no-longer-needed pages at the end of a table.
> You mean symptoms like multiple index tuples pointing to the same heap
> tuple, thus presenting the same heap tuple twice during an index scan,
> don't you?
Yup, exactly :-(
regards, tom lane