postgresql.git/configure, branch master

Add errdetail() with PID and UID about source of termination signal.

2026-04-07T14:22:33+00:00

When a backend is terminated via pg_terminate_backend() or an external SIGTERM, the error message now includes the sender's PID and UID as errdetail, making it easier to identify the source of unexpected terminations in multi-user environments. On platforms that support SA_SIGINFO (Linux, FreeBSD, and most modern Unix systems), the signal handler captures si_pid and si_uid from the siginfo_t structure. On platforms without SA_SIGINFO, the detail is simply omitted. Author: Jakub Wartak Reviewed-by: Andrew Dunstan Reviewed-by: Chao Li <1356863904@qq.com> Discussion: https://postgr.es/m/CAKZiRmyrOWovZSdixpLd3PGMQXuQL_zw2Ght5XhHCkQ1uDsxjw@mail.gmail.com

Compute CRC32C on ARM using the Crypto Extension where available

2026-04-04T13:47:01+00:00

In similar vein to commit 3c6e8c123, the ARMv8 cryptography extension has 64x64 -> 128-bit carryless multiplication instructions suitable for computing CRC. This was tested to be around twice as fast as scalar CRC instructions for longer inputs. We now do a runtime check, even for builds that target "armv8-a+crc", but those builds can still use a direct call for constant inputs, which we assume are short. As for x86, the MIT-licensed implementation was generated with the "generate" program from https://github.com/corsix/fast-crc32/ Reviewed-by: Nathan Bossart Discussion: https://postgr.es/m/CANWCAZaKhE+RD5KKouUFoxx1EbUNrNhcduM1VQ=DkSDadNEFng@mail.gmail.com

Use AVX2 for calculating page checksums where available

2026-04-04T11:07:15+00:00

We already rely on autovectorization for computing page checksums, but on x86 we can get a further several-fold performance increase by annotating pg_checksum_block() with a function target attribute for the AVX2 instruction set extension. Not only does that use 256-bit registers, it can also use vector multiplication rather than the vector shifts and adds used in SSE2. Similar to other hardware-specific paths, we set a function pointer on first use. We don't bother to avoid this on platforms without AVX2 since the overhead of indirect calls doesn't matter for multi-kilobyte inputs. However, we do arrange so that only core has the function pointer mechanism. External programs will continue to build a normal static function and don't need to be aware of this. This matters most when using io_uring since in that case the checksum computation is not done in parallel by IO workers. Co-authored-by: Matthew Sterrett Co-authored-by: Andrew Kim Reviewed-by: Oleg Tselebrovskiy Tested-by: Ants Aasma Tested-by: Stepan Neretin (earlier version) Discussion: https://postgr.es/m/CA+vA85_5GTu+HHniSbvvP+8k3=xZO=WE84NPwiKyxztqvpfZ3Q@mail.gmail.com Discussion: https://postgr.es/m/20250911054220.3784-1-root%40ip-172-31-36-228.ec2.internal

Check for cpuidex and get_cpuid_count separately

2026-04-02T12:39:57+00:00

Previously we would only check for the availability of __cpuidex if the related __get_cpuid_count was not available on a platform. Future commits will need to access hypervisor information about the TSC frequency of x86 CPUs. For that case __cpuidex is the only viable option for accessing a high leaf (e.g. 0x40000000), since __get_cpuid_count does not allow that. __cpuidex is defined in cpuid.h for gcc/clang, but in intrin.h for MSVC, so adjust tests to suite. We also need to cast the array of unsigned ints to signed, since gcc (with -Wall) and clang emit warnings otherwise. Author: Lukas Fittl Reviewed-by: Andres Freund Reviewed-by: John Naylor Discussion: https://postgr.es/m/CAP53PkyooCeR8YV0BUD_xC7oTZESHz8OdA=tP7pBRHFVQ9xtKg@mail.gmail.com

Add warning option -Wold-style-declaration

2026-03-30T21:34:13+00:00

This warning has been triggered a few times via the buildfarm (see commits 8212625e53f, 2b7259f8557, afe86a9e73b), so we might as well add it so that everyone sees it. (This is completely separate from the recently added -Wold-style-definition.) Reviewed-by: Tom Lane Reviewed-by: Bertrand Drouvot Discussion: https://www.postgresql.org/message-id/flat/aa73q1aT0A3/vke/%40ip-10-97-1-34.eu-west-3.compute.internal

configure: Apply -Werror=vla to C++ as well as C

2026-03-30T18:55:16+00:00

The comment part of d9dd406fe281 mentioned that -Wvla is not applicable for C++. That is not fully correct: it is true that VLAs are not part of the C++ standard, and g++ with -pedantic will also warn about them as a non-standard extension. However, -Wvla itself works fine in C++ and will catch VLA usage just as in C. Fix configure.ac to apply -Werror=vla to C++ as well. There is no need to fix meson.build as it already includes it in common_warning_flags. Author: Bertrand Drouvot Suggested-by: Peter Eisentraut Discussion: https://postgr.es/m/7bf60ab1-2b5d-4a77-93ce-815072a0a014%40eisentraut.org

Remove compiler warning option -Wendif-labels

2026-03-25T14:04:18+00:00

This warning has always been on by default in GCC (and in Clang at least going back to 3.1), so we don't need the option explicitly. Reviewed-by: Tom Lane Reviewed-by: Bertrand Drouvot Discussion: https://www.postgresql.org/message-id/flat/aa73q1aT0A3/vke/%40ip-10-97-1-34.eu-west-3.compute.internal

Enable -Wstrict-prototypes and -Wold-style-definition by default

2026-03-18T13:31:50+00:00

Those are available in all gcc and clang versions that support C11 and as C11 is required as of f5e0186f865c, then we can add them without capability test. Having them enabled by default avoid having to chase these manually like 11171fe1fc8, cdf4b9aff2, 0e72b9d440, 7069dbcc31, f1283ed6cc, 7b66e2c086, e95126cf04 and 9f7c527af3 have done. Also, readline headers trigger a lot of warnings with -Wstrict-prototypes, so we make use of the system_header pragma to hide the warnings. Author: Bertrand Drouvot Discussion: https://postgr.es/m/13d51b20-a69c-4ac1-8546-ec4fc278064f%40eisentraut.org Discussion: https://postgr.es/m/aTFctZwWSpl2/LG5%40ip-10-97-1-34.eu-west-3.compute.internal

ssl: Serverside SNI support for libpq

2026-03-18T11:37:11+00:00

Support for SNI was added to clientside libpq in 5c55dc8b4733 with the sslsni parameter, but there was no support for utilizing it serverside. This adds support for serverside SNI such that certificate/key handling is available per host. A new config file, $datadir/pg_hosts.conf, is used for configuring which certificate and key should be used for which hostname. In order to use SNI the ssl_sni GUC must be set to on, when it is off the ssl configuration works just like before. If ssl_sni is enabled and pg_hosts.conf is non-empty it will take precedence over the regular SSL GUCs, if it is empty or missing the regular GUCs will be used just as before this commit with no hostname specific handling. The TLS init hook is not compatible with ssl_sni since it operates on a single TLS configuration and SNI break that assumption. If the init hook and ssl_sni are both enabled, a WARNING will be issued. Host configuration can either be for a literal hostname to match, non- SNI connections using the no_sni keyword or a default fallback matching all connections. By omitting no_sni and the fallback a strict mode can be achieved where only connections using sslsni=1 and a specified hostname are allowed. CRL file(s) are applied from postgresql.conf to all configured hostnames. Serverside SNI requires OpenSSL, currently LibreSSL does not support the required infrastructure to update the SSL context during the TLS handshake. Author: Daniel Gustafsson Co-authored-by: Jacob Champion Reviewed-by: Jacob Champion Reviewed-by: Zsolt Parragi Reviewed-by: Chao Li Reviewed-by: Dewei Dai Reviewed-by: Cary Huang Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/1C81CD0D-407E-44F9-833A-DD0331C202E5@yesql.se

Hardcode override of typeof_unqual for clang-for-bitcode

2026-03-16T18:24:49+00:00

The fundamental problem is that when we call clang to generate bitcode, we might be using configure results from a different compiler, which might not be fully compatible with the clang we are using. In practice, clang supports most things other compilers support, so this has apparently not been a problem in practice. But commits 4cfce4e62c8, 0af05b5dbb4, and 59292f7aac7 have been struggling to make typeof_unqual work in this situation. Clang added support in version 19, GCC in version 14, so if you are using, say, GCC 14 and Clang 16, the compilation with the latter will fail. Such combinations are not very likely in practice, because GCC 14 and Clang 19 were released within a few months of each other, and so Linux distributions are likely to have suitable combinations. But some buildfarm members and some Fedora versions are affected, so this tries to fix it. The fully correct solution would be to run a separate set of configure tests for that clang-for-bitcode, but that would be very difficult to implement, and probably of limited use in practice. So the workaround here is that we hardcodedly override the configure result under clang based on the version number. As long as we only have a few of these cases, this should be manageable. Also swap the order of the tests of typeof_unqual: Commit 59292f7aac7 tested the underscore variant first, but the reasons for that are now gone. Reviewed-by: Jelte Fennema-Nio Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/92f9750f-c7f6-42d8-9a4a-85a3cbe808f3%40eisentraut.org