Horton

Re: Improve LWLock tranche name visibility across backends

Sami Imseih <samimseih@gmail.com>

View thread View on postgr.es
From: Sami Imseih <samimseih@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, Rahila Syed <rahilasyed90@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-18T22:53:44Z
Lists: pgsql-hackers 
> I've been staring at the latest patch for a bit, and I'm a bit concerned
> at how much complexity it adds.

The complexity is the fact we have to track a dsa_pointer that points
to an array of dsa_pointers that track the tranche names. We also
do have to copy the array of dsa_pointers into a new pointer when
enlarging. That adds some complexity that dshash would hide away,
but I don't think it's overly complex.

> I know we were trying to avoid using
> dshash earlier, if for no other reason than it's perhaps not the best data
> structure for the job,

yeah, we really just need an append only structure, so dshash did not
seems unnecessary. But also, we moved away from dshash before it was
decided to have a local cache. Perhaps, it's ok now to go back to dshash
considering that it will only be used in rare scenarios: creations of
new tranches and
syncs to local memory. Most of the time the tranches will be satisfied
directly from local cache.

> (or some other shmem-based
> data structure we have yet to introduce, like a dslist/dsarray).

This will be an interesting API to invest time in, if there could be more
use-cases. I think it's a separate discussion at this point.

--
Sami

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