Re: Missing calls to UnlockBuffers() - unify error handling?

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Missing calls to UnlockBuffers() - unify error handling?
Date: 2025-11-07 22:49:46
Message-ID: m2qbmfj2lld6qdvrairgz2asmzfacmxzydrxfcig4byuaobqfg@bd74vkn5awgw
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-11-07 22:50:04 Re: postmaster uses more CPU in 18 beta1 with io_method=io_uring
Previous Message Manni Wood 2025-11-07 22:38:32 Re: [PATCH] Add pg_get_tablespace_ddl() function to reconstruct CREATE TABLESPACE statement