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
