Re: 64-bit wait_event and introduction of 32-bit wait_event_arg
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Jakub Wartak <jakub.wartak@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-14T08:38:51Z
Lists: pgsql-hackers
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?). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com