pgsql: Fix race condition between relation extension and vacuum. - Mailing list pgsql-committers

From Andres Freund
Subject pgsql: Fix race condition between relation extension and vacuum.
Date
Msg-id E1goGdQ-00031X-Pi@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Fix race condition between relation extension and vacuum.

In e6799d5a5301 I removed vacuumlazy.c trickery around re-checking
whether a page is actually empty after acquiring an extension lock on
the relation, because the page is not PageInit()ed anymore, and
entries in the FSM ought not to lead to user-visible errors.

As reported by various buildfarm animals that is not correct, given
the way to code currently stands: If vacuum processes a page that's
just been newly added by either RelationGetBufferForTuple() or
RelationAddExtraBlocks(), it could add that page to the FSM and it
could be reused by other backends, before those two functions check
whether the newly added page is actually new.  That's a relatively
narrow race, but several buildfarm machines appear to be able to hit
it.

While it seems wrong that the FSM, given it's lack of durability and
approximative nature, can trigger errors like this, that seems better
fixed in a separate commit. Especially given that a good portion of
the buildfarm is red, and this is just re-introducing logic that
existed a few hours ago.

Author: Andres Freund
Discussion: https://postgr.es/m/20190128222259.zhi7ovzgtkft6em6@alap3.anarazel.de

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/fc02e6724f3ce069b33284bce092052ab55bd751

Modified Files
--------------
src/backend/access/heap/vacuumlazy.c | 36 +++++++++++++++++++++++++++++++-----
1 file changed, 31 insertions(+), 5 deletions(-)


pgsql-committers by date:

Previous
From: Tomas Vondra
Date:
Subject: pgsql: Separate per-batch and per-tuple memory contexts in COPY
Next
From: Andres Freund
Date:
Subject: pgsql: Revert "Move page initialization from RelationAddExtraBlocks()t