Horton
Menu

Re: Buffer locking is special (hints, checksums, AIO writes)

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alexander Lakhin <exclusion@gmail.com>, Chao Li <li.evan.chao@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Melanie Plageman <melanieplageman@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@gmail.com>, Noah Misch <noah@leadboat.com>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2026-01-24T23:03:00Z
Lists: pgsql-hackers 
Hi,

On 2026-01-24 16:11:47 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I think this is more likely to be a spgist bug, not a bug in the patch.  From
> > what I can tell, spgist tries to conditionally lock a buffer that it itself
> > already has locked exclusively - that's why the assertion is failing.
> 
> I dunno.  It looks to me like the previous LWLock-based implementation
> of ConditionalLockBuffer() had no such restriction as
> 
> 	/*
> 	 * We better not already hold a lock on the buffer.
> 	 */
> 	Assert(entry->data.lockmode == BUFFER_LOCK_UNLOCK);
> 
> Maybe I'm missing something, but it looks like the old code would
> return false if the buffer was already locked, whether that lock
> was held by our process or another one.

Yea. I added that assert when (I think) Melanie complained that the new code
wouldn't detect repeated acquisitions or release of the same content lock as
nicely as before.  I guess I went a bit overboard and also added the assertion
to ConditionalLockBuffer().

I'll go and move it into the branch where we actually got the lock, that seems
worth continuing to do.


> > We could of course just accept this case and have the conditional lock
> > acquisition fail, but I think trying to conditionally lock a buffer that you
> > already lock is indicative of something having gone wrong.
> 
> I don't really buy this argument.  Yes, within a single function it'd
> be silly to lock a buffer and immediately try to lock it again, but
> when you consider cases like recursive modifications of index state,
> it's *far* from obvious that some lower recursion level might not try
> to lock a buffer that some outer level already locked.

Yea, there's probably something too that. But I'm not entirely convinced -
consider what happens with an index on a temporary table: A higher level think
it got a buffer with space, but then a lower level uses up that space...


> In the case at hand I think it is probably driven by two recursion levels
> trying to acquire free space out of the same buffer.  SPGist is expecting
> the lower level to fail to get the lock and then go find some free space
> elsewhere.  Yeah, we could probably re-code it to get that outcome in
> another way, but why?

Regardless of the assertion, it still feels like there may be something off
here. Why is the page marked as empty in the FSM, despite actually not being
empty?


Greetings,

Andres Freund

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. bufmgr: Fix ordering of checks in PinBuffer()

  2. Use UnlockReleaseBuffer() in more places

  3. bufmgr: Make UnlockReleaseBuffer() more efficient

  4. bufmgr: Don't copy pages while writing out

  5. Fix use of wrong variable in _hash_kill_items()

  6. Fix bug due to confusion about what IsMVCCSnapshot means

  7. bufmgr: Switch to standard order in MarkBufferDirtyHint()

  8. bufmgr: Remove the, now obsolete, BM_JUST_DIRTIED

  9. Require share-exclusive lock to set hint bits and to flush

  10. heapam: Don't mimic MarkBufferDirtyHint() in inplace updates

  11. bufmgr: Allow conditionally locking of already locked buffer

  12. bufmgr: Avoid spurious compiler warning after fcb9c977aa5

  13. lwlock: Remove ForEachLWLockHeldByMe

  14. lwlock: Remove support for disowned lwlwocks

  15. bufmgr: Implement buffer content locks independently of lwlocks

  16. bufmgr: Change BufferDesc.state to be a 64-bit atomic

  17. lwlock: Improve local variable name

  18. lwlock: Invert meaning of LW_FLAG_RELEASE_OK

  19. bufmgr: Make definitions related to buffer descriptor easier to modify

  20. heapam: Add batch mode mvcc check and use it in page mode

  21. freespace: Don't modify page without any lock

  22. heapam: Move logic to handle HEAP_MOVED into a helper function

  23. bufmgr: Optimize & harmonize LockBufHdr(), LWLockWaitListLock()

  24. bufmgr: Add one-entry cache for private refcount

  25. bufmgr: Separate keys for private refcount infrastructure

  26. Add pg_atomic_unlocked_write_u64

  27. Rename BUFFERPIN wait event class to BUFFER

  28. bufmgr: Turn BUFFER_LOCK_* into an enum

  29. lwlock: Fix, currently harmless, bug in LWLockWakeup()

  30. bufmgr: Use atomic sub for unpinning buffers

  31. bufmgr: Allow some buffer state modifications while holding header lock

  32. bufmgr: Fix valgrind checking for buffers pinned in StrategyGetBuffer()

  33. bufmgr: Don't lock buffer header in StrategyGetBuffer()

  34. bufmgr: fewer calls to BufferDescriptorGetContentLock

  35. bufmgr: Fix signedness of mask variable in BufferSync()

  36. bufmgr: Introduce FlushUnlockedBuffer

  37. Improve ReadRecentBuffer() scalability