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

On Wed, Jan 14, 2026 at 9:38 AM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
>
> Hi,
>
> On Fri, Jan 09, 2026 at 11:34:09AM +0100, Jakub Wartak wrote:
> > On Tue, Dec 9, 2025 at 10:11 AM Jakub Wartak
> > <jakub.wartak@enterprisedb.com> wrote:
> > >
> > > Hi Heikki, thanks for having a look!
> > >
> > > On Mon, Dec 8, 2025 at 11:12 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > > >
> > > > 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.
> > >
> > > Right, I'm very interested in hearing what could be added there/what
> > > people want (bonus points if that is causing some performance issues
> > > today and we do not have the area covered and exposing that would fit
> > > in 32-bits ;) )
> > >
> >
> > OK, so v3 is attached. Changes in v3:
>
> Thanks for the new version!
>
> It looks like that it needs a rebase. Also, FWIW, a quick scan shows a few
> numbers of "XXX" and elog calls commented out (that are probably used during
> your own debugging?).

Yes, indeed, that's intentional right now - it's more like a draft
rather than something that should be polished.

To be honest I would like to avoid sinking more time on it, if the
sole idea gets shot down or there is opposition due e.g. to concerns
of exposing 32-bit relfilenodes that way (see that  56-bit relfilenode
idea).

-J.