Re: Missing calls to UnlockBuffers() - unify error handling? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Missing calls to UnlockBuffers() - unify error handling?
Date
Msg-id m2qbmfj2lld6qdvrairgz2asmzfacmxzydrxfcig4byuaobqfg@bd74vkn5awgw
Whole thread Raw
In response to Missing calls to UnlockBuffers() - unify error handling?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 2025-11-06 10:34:58 -0500, Andres Freund wrote:
> While hacking on a patch to "inline" the lock implementation of content locks
> into storage/buffer/, I looked at the callers of UnlockBuffers() and compared
> them to the callers of LWLockReleaseAll().
> 
> Somewhat disconcertingly, there are more callers of LWLockReleaseAll(),
> without - afaict - analysis whether that's right.

A related issue I just found is that ProcKill() calls
SyncRepCleanupAtProcExit() before LWLockReleaseAll(). Which, given that
LWLockReleaseAll() uses lwlocks, doesn't seem great.

This may have kinda been ok in the past, as we'd normally have gone through
AbortTransaction() by that point. However, that's e.g. not true in background
workers, which just rely on ProcKill():

        /*
         * Do we need more cleanup here?  For shmem-connected bgworkers, we
         * will call InitProcess below, which will install ProcKill as exit
         * callback.  That will take care of releasing locks, etc.
         */

Seems we should just reorder the sequence in ProcKill() to first call
LWLockReleaseAll().

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Manni Wood
Date:
Subject: Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement
Next
From: Tomas Vondra
Date:
Subject: Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring