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
signature.asc
Description: PGP signature
