Re: Double content-lock acquisition silently leaks a lock - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Double content-lock acquisition silently leaks a lock
Date
Msg-id 44ej6f2rf6ew42o5xdrmwckkprvuhox3547b3inudlrmdmgwse@rgv3ujkgs2tl
Whole thread
In response to Re: Double content-lock acquisition silently leaks a lock  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2026-09-22 11:15:11 -0400, Andres Freund wrote:
> On 2026-09-22 14:54:33 +0000, Greg Burd wrote:
> > BufferLockAcquire() only asserts that the current backend does not already hold
> > a content lock on the buffer.  I hit that assertion on a buildfarm animal, and
> > while chasing it I convinced myself that the non-assert behaviour is worse than
> > the crash in that it can permanently wedges the buffer.
> 
> That's completely normal for assertion paths IME.
> 
> 
> > Patch attached to turn the assertion into an error.  I am not proposing it
> > as the whole fix; details and an open question below.
> 
> -0.5, it shows up in profiles for me. If we had support for something like
> production assertions, with a lower overhead, I'd maybe +0.5 instead, but we
> don't.
> 
> And I am fundamentally opposed to not make this an assertion failure. This is
> a fundamentally broken program, that needs to trigger assertion
> failures. There's way way too many contexts where an ERROR is basically
> invisible.

Also note that for lwlocks you'd indefinitely hang on a double exclusive
acquisition - no assertion.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Adding a stored generated column without long-lived locks
Next
From: Nitin Jadhav
Date:
Subject: Re: aio: Async fsyncs for crash recovery and checkpointer