Proposed patch for 8.3 VACUUM FULL crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-patches(at)postgreSQL(dot)org
Cc: Tomas Szepe <szepe(at)pinerecords(dot)com>
Subject: Proposed patch for 8.3 VACUUM FULL crash
Date: 2008-02-10 21:21:36
Message-ID: 9622.1202678496@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tomas Szepe reported here
http://archives.postgresql.org/pgsql-bugs/2008-02/msg00068.php
about a bug in VACUUM FULL, which turned out to be that the code
was expecting pages with no live tuples to always get added to
the fraged_pages list, and this was sometimes not happening.

On investigation the problem occurs because we changed vacuum.c's
PageGetFreeSpaceWithFillFactor() to use PageGetHeapFreeSpace()
instead of just computing pd_upper - pd_lower as it had done in
every previous release. This was *not* a good idea: VACUUM FULL
does its own accounting for line pointers and does not need "help".
Aside from exposing the aforementioned bug, this would result in
pages sometimes being passed over as not being useful insertion
targets, when in fact they were going to be completely empty after
the "reaping" step.

The attached proposed patch reverts that bad decision, and also adds an
extra condition to force pages into the fraged_pages list when notup is
true. Under normal circumstances this extra condition should be a
useless test, but I am worried that with extremely small fillfactor
settings it might still be possible to provoke the empty_end_pages
problem.

I am thinking that the extra notup condition should be back-patched,
at least as far back as we have fillfactor support, and maybe all
the way back on general principles.

Comments?

regards, tom lane

Attachment Content-Type Size
unknown_filename text/plain 3.0 KB

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Neil Conway 2008-02-10 22:42:20 Re: NUMERIC key word
Previous Message Decibel! 2008-02-08 18:30:12 Re: 2WRS [WIP]