Re: Improve LWLock tranche name visibility across backends

Hi,

On Thu, Jul 10, 2025 at 04:34:34PM -0500, Sami Imseih wrote:
> Thanks for the feedback!
> 
> > > Attached is a proof of concept that does not alter the
> > > LWLockRegisterTranche API. Instead, it detects when a registration is
> > > performed by a normal backend and stores the tranche name in shared memory,
> > > using a dshash keyed by tranche ID. Tranche name lookup now proceeds in
> > > the order of built-in names, the local list, and finally the shared memory.
> > > The fallback name "extension" can still be returned if an extension does
> > > not register a tranche.
> >
> > I did not look in details, but do you think we could make use of
> > WaitEventCustomNew()?
> 
> It looks like I overlooked the custom wait event, so I didn’t take it into
> account initially. That said, I do think it’s reasonable to consider
> piggybacking on this infrastructure.
> 
> After all, LWLockRegisterTranche is already creating a custom wait event
> defined by the extension.

Right, the tranche is nothing but an eventID (from a wait_event_info point of
view).

> The advantage here is that we can avoid creating
> new shared memory

Right, I think it's good to rely on this existing machinery.

> 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?

> However, WaitEventCustomNew as it currently stands won’t work for our use
> case, since it assigns an eventId automatically. The API currently takes a
> classId and wait_event_name, but in our case, we’d actually want to pass in a
> trancheId.
> 
> So, we might need a new API, something like:
> ```
> WaitEventCustomNewWithEventId(uint32 classId, uint16 eventId,
> const char *wait_event_name);
> ```
> eventId in the LWLock case will be a tracheId that was generated
> by the user in some earlier step, like LWLockInitialize
> 
> This would behave the same as the existing WaitEventCustomNew API,
> except that it uses the provided eventId.
> 
> 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).

Regards,

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