Re: Get rid of WALBufMappingLock - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Get rid of WALBufMappingLock
Date
Msg-id Z8FlYYhQBOkWMHuj@paquier.xyz
Whole thread Raw
In response to Re: Get rid of WALBufMappingLock  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Get rid of WALBufMappingLock
List pgsql-hackers
On Wed, Feb 26, 2025 at 01:48:47PM +0200, Alexander Korotkov wrote:
> Thank you for offering the help.  Updated version of patch is attached
> (I've added one memory barrier there just in case).  I would
> appreciate if you could run it on batta, hachi or similar hardware.

Doing a revert of the revert done in 3fb58625d18f proves that
reproducing the error is not really difficult.  I've done a make
installcheck-world USE_MODULE_DB=1 -j N without assertions, and the
point that saw a failure quickly is one of the tests of pgbench:
PANIC:  could not find WAL buffer for 0/19D366

This one happened for the test "concurrent OID generation" and CREATE
TYPE.  Of course, as it is a race condition, it is random, but it's
taking me only a couple of minutes to see the original issue on my
buildfarm host.  With assertion failures enabled, same story, and same
failure from the pgbench TAP test.

Saying that, I have also done similar tests with your v12 for a couple
of hours and this looks stable under installcheck-world.  I can see
that you've reworked quite a bit the surroundings of InitializedFrom
in this one.  If you apply that once again at some point, the
buildfarm will be judge in the long-term, but I am rather confident by
saying that the situation looks better here, at least.

One thing I would consider doing if you want to gain confidence is
tests like the one I saw causing problems with pgbench, with DDL
patterns stressing specific paths like this CREATE TYPE case.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: long-standing data loss bug in initial sync of logical replication
Next
From: Ashutosh Sharma
Date:
Subject: Re: Orphaned users in PG16 and above can only be managed by Superusers