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. The advantage here is that we can avoid creating
new shared memory and instead reuse the existing static hash table, which is
capped at 128 custom wait events:
```
#define WAIT_EVENT_CUSTOM_HASH_MAX_SIZE 128
```
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?
With this API, we can then teach LWLockRegisterTranche to register the
custom wait event.
--
Sami
