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: Rahila Syed <rahilasyed90@gmail.com>
Cc: Sami Imseih <samimseih@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-09-04T13:51:21Z
Lists: pgsql-hackers 
On Thu, Sep 04, 2025 at 03:29:52PM +0530, Rahila Syed wrote:
> Since updates to LocalLWLockCounter and LWLockTrancheNames are performed
> while holding the lock, but reading LocalLWLockCounter and then
> LWLockTrancheNames in GetLWTrancheName can occur without acquiring the
> same lock in case trancheID < LocalLWLockCounter, There is a small window
> between updating LocalLWLockCounter and adding the name to
> LWLockTrancheNames. During this window, if GetLWTrancheNames is called,
> it might attempt to access a name in LWLockTrancheNames that hasn't been
> added yet.

We hold the lock when reading/writing the shared-memory LWLockCounter.
There's no need to take a lock when reading the backend-local
LocalLWLockCounter, as it can't be modified by any other process.
Additionally, when adding a new tranche name, we hold the lock the entire
time while we bump the shared-memory counter and copy the name, so there's
no chance another backend will see the counter update but not the name or
attempt to use the same LWLockTrancheNames slot.

-- 
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().