pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic - Mailing list pgsql-committers

From Andres Freund
Subject pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic
Date
Msg-id E1Wxuqj-0001Ic-OQ@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Do all-visible handling in lazy_vacuum_page() outside its critical section.

Since fdf9e21196a lazy_vacuum_page() rechecks the all-visible status
of pages in the second pass over the heap. It does so inside a
critical section, but both visibilitymap_test() and
heap_page_is_all_visible() perform operations that should not happen
inside one. The former potentially performs IO and both potentially do
memory allocations.

To fix, simply move all the all-visible handling outside the critical
section. Doing so means that the PD_ALL_VISIBLE on the page won't be
included in the full page image of the HEAP2_CLEAN record anymore. But
that's fine, the flag will be set by the HEAP2_VISIBLE logged later.

Backpatch to 9.3 where the problem was introduced. The bug only came
to light due to the assertion added in 4a170ee9 and isn't likely to
cause problems in production scenarios. The worst outcome is a
avoidable PANIC restart.

This also gets rid of the difference in the order of operations
between master and standby mentioned in 2a8e1ac5.

Per reports from David Leverton and Keith Fiske in bug #10533.

Branch
------
REL9_3_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/46c450c0b04471fc52602520c0a436bda42a3c0d

Modified Files
--------------
src/backend/commands/vacuumlazy.c |   26 +++++++++++++++++---------
1 file changed, 17 insertions(+), 9 deletions(-)


pgsql-committers by date:

Previous
From: Andres Freund
Date:
Subject: pgsql: Do all-visible handling in lazy_vacuum_page() outside its critic
Next
From: Joe Conway
Date:
Subject: pgsql: Clean up data conversion short-lived memory context.