Re: Improve LWLock tranche name visibility across backends

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improve LWLock tranche name visibility across backends
Date: 2025-11-10 16:49:58
Message-ID: aRIXtvkYn1mmyNG5@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 10, 2025 at 10:26:17AM -0600, Nathan Bossart wrote:
> On Mon, Nov 03, 2025 at 11:50:48AM -0600, Sami Imseih wrote:
>>>> I am not sure we need to do anything about this.
>>>
>>> Or maybe we just avoid the tranche_id from leaking
>>> in test_dsa_resowners() by making it a static variable
>>> and checking if we have a valid tranche id before calling
>>> LWLockNewTrancheId()? That is the proper pattern.
>>
>> Like the attached.
>
> It's probably a good idea to avoid tranche leaks, but IMHO there's room for
> improvement in the DSM registry, too. IIUC the problem is that the DSM
> segment is still being added to the registry and found by other backends
> despite the initialization callback failing. My first instinct is that we
> should keep track of whether the DSM segments/DSAs/dshash tables in the
> registry have been fully initialized and to just ERROR in other backends
> when attaching if they aren't. That shouldn't really happen in practice,
> but it'd be good to avoid the strange errors, anyway.

BTW if we really wanted to avoid leaking tranches in test_dsa, we'd need to
store the ID in shared memory. Your patch helps in the case where a single
backend is repeatedly calling test_dsa_resowners(), but other backends
would still allocate their own tranche. I don't see a strong need to fix
this on back-branches, given these functions run exactly once as part of a
test, but fixing it on master seems worthwhile so that extension authors
don't copy/paste this broken code.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2025-11-10 16:50:19 Re: Extend injection_points_attach() to accept a user-defined function
Previous Message Heikki Linnakangas 2025-11-10 16:38:21 Re: Move SLRU_PAGES_PER_SEGMENT to pg_config_manual.h