Re: 64-bit wait_event and introduction of 32-bit wait_event_arg

On Thu, Feb 12, 2026 at 01:42:23PM +0100, Jakub Wartak wrote:
> What's left:
> - Earlier Heikki raised the question "Wait events can be defined in extensions;
> how does an extension plug into this facility?" - that's still unanswered.

Reserving the full 8 bytes to the callers of WaitEventExtensionNew()
and WaitEventInjectionPointNew() would be an error, because we would
forever lock down the possibility for extensions to set at will the 4
extra bytes that become available when setting some extra data in
parallel of a wait event name. The results of these routines should
still be 4 bytes for the "static" part of the wait event names, not 8.

> I think they could just OR 32-bit value themselves, but maybe we could
> just provide a way to plug into pg_get_wait_events().waiteventarg_description?

The value provided back to pg_stat_activity would be a 4-byte integer
under this design, whose interpretation is up to the client, I guess,
with a filter based on the wait event name found (likely a CASE/ELSE
to force casts back to a text value at the end in most cases?). That
may be annoying for client applications, though, but perhaps
acceptable as this provides extra information with a single atomic
write.

At the end, the way these 4 extra bytes can be set by extensions is an
API problem for me, and I suspect that the correct way to extend
things, on top of forcing the use of 4 bytes for the ID of the fixed
event ID (perhaps just define a type here anyway?), would be to patch
the most popular APIs that extensions currently use to let them set
the value they want for the extra 4 bytes. The first choice that
comes into mind here is the family of WaitLatchOrSocket() APIs, that
could have an extra argument with a uint32 for the extra data. That's
a popular one among extension developers.

By the way, patch 0001 includes a log file from pg_plan_advice with
some information I suspect you did not intend to send..
--
Michael