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
