pgsql: Fix race condition between relation extension and vacuum.

Поиск
Список
Период
Сортировка
От Andres Freund
Тема pgsql: Fix race condition between relation extension and vacuum.
Дата
Msg-id E1goGdQ-00031X-Pi@gemulon.postgresql.org
обсуждение исходный текст
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: pgsql: Separate per-batch and per-tuple memory contexts in COPY
Следующее
От: Andres Freund
Дата:
Сообщение: pgsql: Revert "Move page initialization from RelationAddExtraBlocks()t