Re: WAL Insertion Lock Improvements
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Nathan Bossart <nathandbossart@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-25T22:39:37Z
Lists: pgsql-hackers
On Tue, Jul 25, 2023 at 12:57:37PM -0700, Andres Freund wrote: > I just rebased my aio tree over the commit and promptly, on the first run, saw > a hang. I did some debugging on that. Unfortunately repeated runs haven't > repeated that hang, despite quite a bit of trying. > > The symptom I was seeing is that all running backends were stuck in > LWLockWaitForVar(), even though the value they're waiting for had > changed. Which obviously "shouldn't be possible". Hmm. I've also spent a few days looking at this past report that made the LWLock part what it is today, but I don't quite see immediately how it would be possible to reach a state where all the backends are waiting for an update that's not happening: https://www.postgresql.org/message-id/CAMkU=1zLztROwH3B42OXSB04r9ZMeSk3658qEn4_8+b+K3E7nQ@mail.gmail.com All the assumptions of this code and its dependencies with xloginsert.c are hard to come by. > It's of course possible that this is AIO specific, but I didn't see anything > in stacks to suggest that. Or AIO handles the WAL syncs so quickly that it has more chances in showing a race condition here? > I do wonder if this possibly exposed an undocumented prior dependency on the > value update always happening under the list lock. I would not be surprised by that. -- Michael
Commits
-
Optimize pg_atomic_exchange_u32 and pg_atomic_exchange_u64.
- 64b1fb5f0326 17.0 cited
-
Document more assumptions of LWLock variable changes with WAL inserts
- 66d86d4201b3 17.0 landed
-
Optimize WAL insertion lock acquisition and release with some atomics
- 71e4cc6b8ec6 17.0 landed
-
Avoid the use of a separate spinlock to protect a LWLock's wait queue.
- 008608b9d510 9.6.0 cited