On 28/09/2026 18:24, Andres Freund wrote:
Hi,
On 2026-09-28 17:07:52 +0200, Kevin Rocker wrote:
The reason this is more than a cancellation-latency issue on v19 is the
buffer content-lock rewrite in fcb9c977aa5 tracks only one lock per
buffer per backend (the single data.lockmode field). A second SHARE
acquire on an already-share-locked buffer is now:
- a hard Assert/crash in cassert builds (what unicorn shows), and
- in a non-assert build, an asymmetric leak: BufferLockAttempt() adds
a second BM_LOCK_VAL_SHARED to the shared state, data.lockmode
records only one, and release subtracts one -- so that pg_class
buffer is left permanently one shared-locker too high and can never
again be locked exclusive. Any later exclusive waiter (VACUUM) on
that buffer blocks for the life of the cluster.
Pre-v19 the double SHARE was harmless (the held-lwlocks array could
represent it), which is presumably why the call site survived so long.
I think this was completely broken before 19 too. Acquiring a lock while
holding the same lock just happened to be undiagnosed. Note that if you ever
did this with an exclusive lock being involved, you'd just have ended up with
an uninterruptible endless wait.
It surely was never safe to call ProcessConfigFile(), or sane to sleep, while
holding an lwlock. And calling vacuum_delay_point() with interrupts held, made
it not actually properly work, due to not doing the CFI().
+1
I just arrived at this thread from this other thread discussing the same
issue:
https://www.postgresql.org/message-id/19628-c2b17d358181a1ea%40postgresql.org.
I committed and backported the fix to all stable branches. I included a
quick exit in vacuum_delay_point(), if !INTERRUPTS_CAN_BE_PROCESSED().
- Heikki
