Avoid LWLockWaitForVar() for currently held WAL insertion lock in WaitXLogInsertionsToFinish()
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-11-24T12:43:10Z
Lists: pgsql-hackers
Attachments
- v1-0001-Avoid-LWLockWaitForVar-for-currently-held-WAL-ins.patch (application/octet-stream) patch v1-0001
Hi, While working on something else, I noticed that WaitXLogInsertionsToFinish() goes the LWLockWaitForVar() route even for a process that's holding a WAL insertion lock. Typically, a process holding WAL insertion lock reaches WaitXLogInsertionsToFinish() when it's in need of WAL buffer pages for its insertion and waits for other older in-progress WAL insertions to finish. This fact guarantees that the process holding a WAL insertion lock will never have its insertingAt less than 'upto'. With that said, here's a small improvement I can think of, that is, to avoid calling LWLockWaitForVar() for the WAL insertion lock the caller of WaitXLogInsertionsToFinish() currently holds. Since LWLockWaitForVar() does a bunch of things - holds interrupts, does atomic reads, acquires and releases wait list lock and so on, avoiding it may be a good idea IMO. I'm attaching a patch herewith. Here's the cirrus-ci tests - https://github.com/BRupireddy/postgres/tree/avoid_LWLockWaitForVar_for_currently_held_wal_ins_lock_v1. Thoughts? -- Bharath Rupireddy PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
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