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

On Mon, Dec 8, 2025 at 12:27 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> 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

Hi Bertrand, thanks for the link. I've responded to Heikki, but Your
thread (and feedback You got) was one of the directions of why not to
add anything there beyond just using a more powerful(longer) registry
for free.

-J.