Обсуждение: pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away

Поиск
Список
Период
Сортировка

pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away

От
tgl@postgresql.org (Tom Lane)
Дата:
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)

Re: pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away

От
Jan Wieck
Дата:
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 #

Re: pgsql: Fix aboriginal mistake in lazy VACUUM's code for truncating away

От
Tom Lane
Дата:
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