Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+ - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+
Date
Msg-id CA+U5nMLBUjUz9HR0yqmTLq523MreEtqSkDb3j1KAhxhGnMQU_g@mail.gmail.com
Whole thread Raw
In response to Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 9 December 2013 21:24, Bruce Momjian <bruce@momjian.us> wrote:
>
> Where are we on this?

Good question, see below.

>> In those commits, lazy_vacuum_heap() skipped pinned blocks, but then
>> failed to report that accurately, claiming that the tuples were
>> actually removed when they were not. That bug has masked the effect of
>> the page skipping behaviour.

Wow, this is more complex than just that. Can't foresee backpatching anything.

We prune rows down to dead item pointers. Then we remove from the
index, then we try to remove them from heap, but may skip removal for
some blocks.

The user description of that is just wrong and needs more thought and work.

-- Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Compression of tables
Next
From: KONDO Mitsumasa
Date:
Subject: Re: Optimize kernel readahead using buffer access strategy