Re: Improve LWLock tranche name visibility across backends
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-07-10T21:34:34Z
Lists: pgsql-hackers
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
Commits
-
test_dsa: Avoid leaking LWLock tranches.
- c5c74282f2ea 19 (unreleased) landed
-
Teach DSM registry to ERROR if attaching to an uninitialized entry.
- b26d76f64327 18.2 landed
- ac2800ddc185 17.8 landed
- 1165a933aab1 19 (unreleased) landed
-
Add a test harness for the LWLock tranche code.
- 16607718c010 19 (unreleased) landed
-
Revert recent change to RequestNamedLWLockTranche().
- d814d7fc3d52 19 (unreleased) landed
-
Move dynamically-allocated LWLock tranche names to shared memory.
- 38b602b0289f 19 (unreleased) landed
-
Prepare DSM registry for upcoming changes to LWLock tranche names.
- 5487058b56e0 19 (unreleased) landed
-
Add GetNamedDSA() and GetNamedDSHash().
- fe07100e82b0 19 (unreleased) cited