]> granicus.if.org Git - postgresql/commitdiff
Fix spurious warning after vacuuming a page on a table with no indexes.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Thu, 26 Sep 2013 08:24:40 +0000 (11:24 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Thu, 26 Sep 2013 08:38:15 +0000 (11:38 +0300)
There is a rare race condition, when a transaction that inserted a tuple
aborts while vacuum is processing the page containing the inserted tuple.
Vacuum prunes the page first, which normally removes any dead tuples, but
if the inserting transaction aborts right after that, the loop after
pruning will see a dead tuple and remove it instead. That's OK, but if the
page is on a table with no indexes, and the page becomes completely empty
after removing the dead tuple (or tuples) on it, it will be immediately
marked as all-visible. That's OK, but the sanity check in vacuum would
throw a warning because it thinks that the page contains dead tuples and
was nevertheless marked as all-visible, even though it just vacuumed away
the dead tuples and so it doesn't actually contain any.

Spotted this while reading the code. It's difficult to hit the race
condition otherwise, but can be done by putting a breakpoint after the
heap_page_prune() call.

Backpatch all the way to 8.4, where this code first appeared.

src/backend/commands/vacuumlazy.c

index f80a8dc8cea9c658536673bbd704c4945a90dff0..78b40c55fc965fcb7e798206d76c545779810876 100644 (file)
@@ -899,6 +899,7 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
                {
                        /* Remove tuples from heap */
                        lazy_vacuum_page(onerel, blkno, buf, 0, vacrelstats, &vmbuffer);
+                       has_dead_tuples = false;
 
                        /*
                         * Forget the now-vacuumed tuples, and press on, but be careful