Horton

Re: Improve LWLock tranche name visibility across backends

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-10T16:26:17Z
Lists: pgsql-hackers 
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.

-- 
nathan

Commits

  1. test_dsa: Avoid leaking LWLock tranches.

  2. Teach DSM registry to ERROR if attaching to an uninitialized entry.

  3. Add a test harness for the LWLock tranche code.

  4. Revert recent change to RequestNamedLWLockTranche().

  5. Move dynamically-allocated LWLock tranche names to shared memory.

  6. Prepare DSM registry for upcoming changes to LWLock tranche names.

  7. Add GetNamedDSA() and GetNamedDSHash().