BUG #19368: f54af9f does not create the correct macro for autotools build

PG Bug reporting form <noreply@postgresql.org> writes:

The commit f54af9f2679d added a macro HAVE_LIBURING_QUEUE_INIT_MEM that is
checked to see if slowdown from memory mappings can be avoided when using
io_uring.
This HAVE_LIBURING_QUEUE_INIT_MEM is set by Meson build after checking
liburing.
However, the autotools build seems to set a different macro,
HAVE_IO_URING_QUEUE_INIT_MEM, which is never used.

This means when the server is built with autotools, the slowdown when using
io_uring can never be avoided.

This is indeed busted, but I'd argue that the autoconf build has the
right macro name and meson and the C code are using the wrong one:

if cc.has_function('io_uring_queue_init_mem',
dependencies: liburing, args: test_c_args)
cdata.set('HAVE_LIBURING_QUEUE_INIT_MEM', 1)
endif

That's clearly not following the "HAVE_function" convention.

regards, tom lane

On Wed, Dec 31, 2025 at 7:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

PG Bug reporting form <noreply@postgresql.org> writes:

The commit f54af9f2679d added a macro HAVE_LIBURING_QUEUE_INIT_MEM that is
checked to see if slowdown from memory mappings can be avoided when using
io_uring.
This HAVE_LIBURING_QUEUE_INIT_MEM is set by Meson build after checking
liburing.
However, the autotools build seems to set a different macro,
HAVE_IO_URING_QUEUE_INIT_MEM, which is never used.

This means when the server is built with autotools, the slowdown when using
io_uring can never be avoided.

This is indeed busted, but I'd argue that the autoconf build has the
right macro name and meson and the C code are using the wrong one:

if cc.has_function('io_uring_queue_init_mem',
dependencies: liburing, args: test_c_args)
cdata.set('HAVE_LIBURING_QUEUE_INIT_MEM', 1)
endif

That's clearly not following the "HAVE_function" convention.

Agreed. The attached patch should fix the issue.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Masahiko Sawada <sawada.mshk@gmail.com> writes:

On Wed, Dec 31, 2025 at 7:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

This is indeed busted, but I'd argue that the autoconf build has the
right macro name and meson and the C code are using the wrong one:

Agreed. The attached patch should fix the issue.

You beat me to it ;-). Patch LGTM.

regards, tom lane

On Wed, Dec 31, 2025 at 8:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Masahiko Sawada <sawada.mshk@gmail.com> writes:

On Wed, Dec 31, 2025 at 7:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

This is indeed busted, but I'd argue that the autoconf build has the
right macro name and meson and the C code are using the wrong one:

Agreed. The attached patch should fix the issue.

You beat me to it ;-). Patch LGTM.

Thank you for reviewing the patch! Pushed.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Hi,

On 2025-12-31 11:20:17 -0800, Masahiko Sawada wrote:

On Wed, Dec 31, 2025 at 8:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Masahiko Sawada <sawada.mshk@gmail.com> writes:

On Wed, Dec 31, 2025 at 7:59 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

This is indeed busted, but I'd argue that the autoconf build has the
right macro name and meson and the C code are using the wrong one:

Ugh, yea, not sure what I running on that day.

Agreed. The attached patch should fix the issue.

You beat me to it ;-). Patch LGTM.

Thank you for reviewing the patch! Pushed.

Thanks!

Greetings,

Andres Freund