Re: Proposed patch for 8.3 VACUUM FULL crash

Lists: pgsql-patches
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
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

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgreSQL(dot)org>
Subject: Re: Proposed patch for 8.3 VACUUM FULL crash
Date: 2008-02-11 21:29:15
Message-ID: 87ve4vkwr8.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches


"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> 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".

Fwiw this change appears to have crept in when the patch was merged.
Ironically while most of us have been complaining about patches not being
widely visible and tested outside of CVS in this case we perhaps suffered from
the opposite problem. The patch was fairly heavily tested on this end before
it was posted and I'm not sure those tests have been repeated since the merge.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!


From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Proposed patch for 8.3 VACUUM FULL crash
Date: 2008-02-11 21:32:48
Message-ID: 9865.1202765568@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-patches

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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".

> Fwiw this change appears to have crept in when the patch was merged.

Yeah, it's entirely likely that this was my fault :-(. It wasn't
apparent at the time that this change wasn't safe and conservative...

regards, tom lane