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

Hi,

On Mon, Dec 08, 2025 at 12:12:27PM +0200, Heikki Linnakangas wrote:
> On 08/12/2025 11:54, Jakub Wartak wrote:

Thanks for working on this!

> > 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?

I worked on something similar in the past (see [1]) and ended up providing the extra
information that way:

pid | wait_event_type | wait_event | infos
---------+-----------------+--------------+-------------------------------------------------------------
2560105 | IO | DataFileRead | {"blocknum" : "9272", "dbnode" : "5", "relnode" : "16407"}
2560135 | IO | WalSync | {"segno" : "1", "tli" : "1"}
2560138 | IO | DataFileRead | {"blocknum" : "78408", "dbnode" : "5", "relnode" : "16399"}

The "descriptions" were added in wait_event_names.txt, for example,

+DATA_FILE_READ "Waiting for a read from a relation data file." "blocknum" "dbnode" "relnode"

and the json was build only at query time. Maybe that could be an option to expose
the values and the descriptions in the same field.

[1]: https://www.postgresql.org/message-id/aIIeX7p2cKUO6KTa@ip-10-97-1-34.eu-west-3.compute.internal

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com