Re: Improve LWLock tranche name visibility across backends

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-15T10:18:16Z
Lists: pgsql-hackers
Hi,

On Fri, Jul 11, 2025 at 04:32:13PM -0500, Sami Imseih wrote:
> > > and instead reuse the existing static hash table, which is
> > > capped at 128 custom wait events:
> > >
> > > ```
> > > #define WAIT_EVENT_CUSTOM_HASH_MAX_SIZE 128
> > > ```
> >
> > That's probably still high enough, thoughts?
> 
> I have no reason to believe that this number could be too low.
> I am not aware of an extension that will initialize more than a
> couple of LWLocks.
> 
> > > or maybe we can just allow WaitEventCustomNew to take in the eventId, and
> > > if it's > 0, then use the passed in value, otherwise generate the next eventId.
> > >
> > > I do like the latter approach more, what do you think?
> >
> > I think I do prefer it too, but in both cases we'll have to make sure there
> > is no collision on the eventID (LWTRANCHE_FIRST_USER_DEFINED is currently
> > 95).
> 
> As far as collisions are concerned, the key of the hash is the wait_event_info,
> which is a bitwise OR of classId and eventId
> ```
> wait_event_info = classId | eventId;
> ```
> Do you think collision can still be possible?

I meant to say collision between the trancheID and WaitEventCustomCounter->nextId

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



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