mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-12-21 08:29:39 +08:00
Fix spurious warning after vacuuming a page on a table with no indexes.
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.
This commit is contained in:
parent
c2df45a37c
commit
adaba2751f
@ -900,6 +900,7 @@ lazy_scan_heap(Relation onerel, LVRelStats *vacrelstats,
|
|||||||
{
|
{
|
||||||
/* Remove tuples from heap */
|
/* Remove tuples from heap */
|
||||||
lazy_vacuum_page(onerel, blkno, buf, 0, vacrelstats, &vmbuffer);
|
lazy_vacuum_page(onerel, blkno, buf, 0, vacrelstats, &vmbuffer);
|
||||||
|
has_dead_tuples = false;
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* Forget the now-vacuumed tuples, and press on, but be careful
|
* Forget the now-vacuumed tuples, and press on, but be careful
|
||||||
|
Loading…
Reference in New Issue
Block a user