Re: Buffer locking is special (hints, checksums, AIO writes)
Andres Freund <andres@anarazel.de>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Require share-exclusive lock to set hint bits and to flush
- 82467f627bd4 19 (unreleased) landed
-
lwlock: Remove ForEachLWLockHeldByMe
- 55fbfb738b00 19 (unreleased) landed
-
bufmgr: Implement buffer content locks independently of lwlocks
- fcb9c977aa5f 19 (unreleased) landed
-
bufmgr: Change BufferDesc.state to be a 64-bit atomic
- dac328c8a682 19 (unreleased) landed
-
heapam: Add batch mode mvcc check and use it in page mode
- 0b96e734c590 19 (unreleased) landed
-
freespace: Don't modify page without any lock
- 45f658dacb9c 19 (unreleased) landed
-
heapam: Move logic to handle HEAP_MOVED into a helper function
- 548de59d93d5 19 (unreleased) landed
-
bufmgr: Optimize & harmonize LockBufHdr(), LWLockWaitListLock()
- 09ae2c8bac8d 19 (unreleased) landed
-
bufmgr: Add one-entry cache for private refcount
- 30df61990c67 19 (unreleased) landed
-
bufmgr: Separate keys for private refcount infrastructure
- edbaaea0a95e 19 (unreleased) landed
-
Add pg_atomic_unlocked_write_u64
- 7902a47c20b1 19 (unreleased) landed
-
Rename BUFFERPIN wait event class to BUFFER
- 6c5c393b7403 19 (unreleased) landed
-
bufmgr: Turn BUFFER_LOCK_* into an enum
- 156680055dc5 19 (unreleased) landed
-
lwlock: Fix, currently harmless, bug in LWLockWakeup()
- 81f773895321 19 (unreleased) landed
- da3971496531 15.16 landed
- 89c8a1b9069f 16.12 landed
- 427e886a79a5 17.8 landed
- 332693e75969 14.21 landed
- 8082b759d9b5 18.2 landed
-
bufmgr: Use atomic sub for unpinning buffers
- 5310fac6e0fc 19 (unreleased) landed
-
bufmgr: Allow some buffer state modifications while holding header lock
- c75ebc657ffc 19 (unreleased) landed
-
bufmgr: Fix valgrind checking for buffers pinned in StrategyGetBuffer()
- c819d1017ddb 19 (unreleased) landed
-
bufmgr: Don't lock buffer header in StrategyGetBuffer()
- 5e8998592879 19 (unreleased) landed
-
bufmgr: fewer calls to BufferDescriptorGetContentLock
- 3baae90013df 19 (unreleased) landed
-
bufmgr: Fix signedness of mask variable in BufferSync()
- 2a2e1b470b9b 19 (unreleased) landed
-
bufmgr: Introduce FlushUnlockedBuffer
- 3c2b97b29ee3 19 (unreleased) landed
-
Improve ReadRecentBuffer() scalability
- 819dc118c0f6 19 (unreleased) landed
Attachments
- v7-0001-bufmgr-Turn-BUFFER_LOCK_-into-an-enum.patch (text/x-diff)
Hi,
On 2025-11-25 11:54:00 -0500, Andres Freund wrote:
> Thanks a lot for that detailed review! A few questions and comments, before I
> try to address the comments in the next version.
Here's that new new version, with the following changes
- Some more micro-optimizations, most importantly adding a commit that doesn't
initialize the delay in LockBufHdr() unless needed. With those I don't see a
consistent slowdown anymore (slight speedup on one workstation, slight
slowdown on another, in an absurdly adverse workload)
- Tried to address Melanie's feedback, with some exceptions (some noted below,
but I also need to make another pass through the reviews)
- re-implemented AssertNotCatalogBufferLock() in the new world
- Substantially expanded comments around setting hint bits (in buffer/README,
heapam_visibility.c and bufmgr.c)
- split out the change to fsm_vacuum_page() to start to lock the page into is
own commit
- reordered patch series so that smaller changes are before the 64bit-state
and "Implement buffer content locks independently of" commits, so they can
be committed while we finish cleaning the later changes
- I didn't invest much in cleaning up the later patches ("Don't copy pages
while writing out" and "Make UnlockReleaseBuffer() more efficient") yet,
wanted to focus on the earlier patches first
Todo:
- still need to rename ResOwnerReleaseBufferPin(). Wondering about what to
rename ResourceOwnerDesc.name to. "buffer ownership" maybe? Not great...
- gistkillitems() complaint by Melanie
- amortize vs batch vs SetHintBits comment + SHB_* names
- for the next version I'll remove the BATCHMVCC_FEWER_ARGS conditionals from
0010. I don't love needing BatchMVCCState but I don't really see an
alternative, the performance difference is pretty persistent.
Questions:
- ForEachLWLockHeldByMe() and LWLockDisown() aren't used anymore, should we
remove them?
Greetings,
Andres Freund