| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in VACUUM reporting of "removed %d row versions" in 9.2+ |
| Date: | 2013-12-10 07:37:55 |
| Message-ID: | CA+U5nMLBUjUz9HR0yqmTLq523MreEtqSkDb3j1KAhxhGnMQU_g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 9 December 2013 21:24, Bruce Momjian <bruce(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | KONDO Mitsumasa | 2013-12-10 08:03:31 | Re: Optimize kernel readahead using buffer access strategy |
| Previous Message | Thomas Munro | 2013-12-10 07:18:40 | Compression of tables |