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 |
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] |