Feedback-ID: id4a34324:Fastmail
Date: Wed, 28 Jan 2026 12:33:01 -0500
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>, 
	Michael Paquier <michael@paquier.xyz>
Cc: Aditya Kamath <Aditya.Kamath1@ibm.com>, 
	Srirama Kucherlapati <sriram.rk@in.ibm.com>, "peter@eisentraut.org" <peter@eisentraut.org>, 
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>, 
	"tristan@partin.io" <tristan@partin.io>, 
	"postgres-ibm-aix@wwpdl.vnet.ibm.com" <postgres-ibm-aix@wwpdl.vnet.ibm.com>
Subject: Re: AIX support
Message-ID: <vua2n6svb6fac3fmz42ahqxndmgbgor7vpxtemis5evasfpzb3@ogs4ewexkpjm>
References: <61d9ecc8-da4e-487a-9774-838b044cda4d@eisentraut.org>
 <SJ4PPFB8177832645802E05CC9DD299E792DB8CA@SJ4PPFB81778326.namprd15.prod.outlook.com>
 <fb505187-907c-4925-9b0a-6391f212dabb@eisentraut.org>
 <SJ4PPFB81778326E995FAD5945ECF752FA1DB96A@SJ4PPFB81778326.namprd15.prod.outlook.com>
 <SJ4PPFB81778326EC35CBFA16B5449CFA97DB94A@SJ4PPFB81778326.namprd15.prod.outlook.com>
 <lx56bdyuajddthcksde62fze7k2oiy3pfczbsuu6ppngcvud7j@cjgb2zem42li>
 <SJ4PPFB817783260F14AB4D9AD2CE247DE8DB91A@SJ4PPFB81778326.namprd15.prod.outlook.com>
 <LV8PR15MB64883FC333B351ABD169E874D691A@LV8PR15MB6488.namprd15.prod.outlook.com>
 <LV8PR15MB64888765A43D229EA5D1CFE6D691A@LV8PR15MB6488.namprd15.prod.outlook.com>
 <CA+TgmoatPGOAfL8Wa3uZ1OGXd34EKOzgm6hXSTa1swS=bbQoag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CA+TgmoatPGOAfL8Wa3uZ1OGXd34EKOzgm6hXSTa1swS=bbQoag@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/vua2n6svb6fac3fmz42ahqxndmgbgor7vpxtemis5evasfpzb3%40ogs4ewexkpjm>
Precedence: bulk

Hi,

On 2026-01-28 10:41:52 -0500, Robert Haas wrote:
> On Wed, Jan 28, 2026 at 10:20 AM Aditya Kamath <Aditya.Kamath1@ibm.com> wrote:
> > But here is the catch. It won’t pick the AIX system float.h. It will pick the Postgres "src/include/utilsfloat.h”.
>
> PostgreSQL's header should always be included as "utils/float.h" and
> the system header should always be included as "float.h" (or, well,
> <float.h>, presumably). So this confusion should not exist unless the
> include paths are messed up. It doesn't seem correct to me that the
> include path includes src/include/utils rather than just src/include,
> but I see the same thing here:

I agree that this is wrong.

CCing Michael and Bertrand, they added this in fa88928470b5 and 1e68e43d3f0f.


> which happens because of:
>
> wait_event = static_library('wait_event_names',
>   waitevent_sources,
>   dependencies: [backend_code],
>   include_directories: include_directories('../../../include/utils'),
>   kwargs: internal_lib_args,
> )
>
> which happens because wait_event_funcs.c contains:
>
> #include "wait_event_funcs_data.c"
>
> and for some reason, that file gets placed in src/include/utils.

The reason for that is that the same invocation also generates
wait_event_types.h, which is included by other headers.


> The attached patch, which also adjusts wait_events.c, fixes it for me.

Unfortunately I suspect that'll cause issues with make builds, because there
the files are generated in a different place (src/backend/activity) and then
only wait_event_types.h is copied to src/include. So including the files as
utils/ won't work.


I'd fix that aspect by doing the same thing in the autoconf build as we do in
meson, i.e. keep the file in the include dir. We already do that e.g. for
guc_tables.inc.c, see this src/backend/utils/Makefile stanza:

# These generated headers must be symlinked into src/include/.
# We use header-stamp to record that we've done this because the symlinks
# themselves may appear older than fmgr-stamp.
$(top_builddir)/src/include/utils/header-stamp: fmgr-stamp errcodes.h probes.h guc_tables.inc.c
	cd '$(dir $@)' && for file in fmgroids.h fmgrprotos.h errcodes.h probes.h guc_tables.inc.c; do \
	  rm -f $$file && $(LN_S) "../../../$(subdir)/$$file" . ; \
	done
	touch $@


Alternatively: I'm not a fan of including .c files that are not actually
working C.  You could just make wait_event_funcs_data.c be a complete C file,
defining waitEventData, that is then built as a standalone file.

Greetings,

Andres Freund