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
