pgsql: Fix ordering issue with WAL operations in GIN fast insert path

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Fix ordering issue with WAL operations in GIN fast insert path
Date: 2022-10-26 00:42:04
Message-ID: E1onUUd-000ojy-UP@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix ordering issue with WAL operations in GIN fast insert path

Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.

First, when using a separate list, XLogBeginInsert() was being always
called before START_CRIT_SECTION(), and in this case a second thing was
wrong when merging lists, as an exclusive lock was taken on the tail
page *before* calling XLogBeginInsert(). Finally, when inserting items
into a tail page, the order of XLogBeginInsert() and
START_CRIT_SECTION() was reversed. This commit addresses all these
issues by moving the calls of XLogBeginInsert() after all the pages
logged are locked and pinned, within a critical section.

This has been applied first only on HEAD as of 56b6625, but as per
discussion with Tom Lane and Álvaro Herrera, a backpatch is preferred to
keep all the branches consistent and to respect the transam's README
where we can.

Author: Matthias van de Meent, Zhang Mingli
Discussion: https://postgr.es/m/CAEze2WhL8uLMqynnnCu1LAPwxD5RKEo0nHV+eXGg_N6ELU88HQ@mail.gmail.com
Backpatch-through: 10

Branch
------
REL_10_STABLE

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

Modified Files
--------------
src/backend/access/gin/ginfast.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2022-10-26 02:40:05 Re: pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows.
Previous Message Justin Pryzby 2022-10-25 23:57:54 Re: pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows.