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

On 08/12/2025 11:54, Jakub Wartak wrote:
> While thinking about cons, the only cons that I could think of is that
> when we would be exposing something as 32-bits , then if the following
> major release changes some internal structure/data type to be a bit
> more heavy, it couldn't be exposed anymore like that  (think of e.g.
> 64-bit OIDs?)
> 
> Any help, opinions, ideas and code/co-authors are more than welcome.
Expanding it to 64 bit seems fine as far as performance is concerned. I 
think the difficult and laborious part is to design the facilities to 
make use of it. For example, if you encode an table OID in it, how do 
you interpret that when you're looking at pg_stat_activity? A new 
pg_explain_wait_event(bigint waitevent) that returns a text 
representation of the event perhaps? Wait events can be defined in 
extensions; how does an extension plug into this facility?

Inevitably, the extra 32 bits won't be enough to expose everything that 
you might want to expose. Should we already think about what to do then? 
For lock waits, for example, should we have another array in shared 
memory with more details, and just store an offset into that array in 
the extra wait event bits, for example? (e already have pg_locks, but 
let's imagine we didn't. How would you design it in a green field scenario?

- Heikki