194 Commits (c6ea528b470f45832437f2a937cf2f4483d23737)

Author	SHA1	Message	Date
Jacob Champion	85b380162c	oauth: Explicitly depend on -pthread ... Followup to 4e1e41733 and 52ecd05ae. oauth-utils.c uses pthread_sigmask(), requiring -pthread on Debian bullseye at minimum. Reported-by: Christoph Berg <myon@debian.org> Tested-by: Christoph Berg <myon@debian.org> Discussion: https://postgr.es/m/aK4PZgC0wuwQ5xSK%40msg.df7cb.de Backpatch-through: 18	2 weeks ago
Peter Eisentraut	f5e0186f86	Raise C requirement to C11 ... This changes configure and meson.build to require at least C11, instead of the previous C99. The installation documentation is updated accordingly. configure.ac previously used AC_PROG_CC_C99 to activate C99. But there is no AC_PROG_CC_C11 in Autoconf 2.69, because it's too old. (Also, post-2.69, the AC_PROG_CC_Cnn macros were deprecated and AC_PROG_CC activates the last supported C mode.) We could update the required Autoconf version, but that might be a separate project that no one wants to undertake at the moment. Instead, we open-code the test for C11 using some inspiration from later Autoconf versions. But instead of writing an elaborate test program, we keep it simple and just check __STDC_VERSION__, which should be good enough in practice. In meson.build, we update the existing C99 test to C11, but again we just check for __STDC_VERSION__. This also removes the separate option for the conforming preprocessor on MSVC, added by commit 8fd9bb1d96, since that is activated automatically in C11 mode. Note, we don't use the "official" way to set the C standard in Meson using the c_std project option, because that is impossible to use correctly (see <https://github.com/mesonbuild/meson/issues/14717>). Reviewed-by: David Rowley <dgrowleyml@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a@eisentraut.org	2 weeks ago
Peter Eisentraut	4a4038068b	meson: Move C99 test earlier ... Move the test for compiler options for C99 earlier in meson.build, before we make use of the compiler for other tests. That way, if any command-line options are needed, subsequent tests will also use them. This is at the moment a theoretical problem, but it seems better to get this correct. It also matches the order in the Autoconf-based build more closely. Discussion: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a@eisentraut.org	4 weeks ago
Andres Freund	01d6832c10	meson: add and use stamp files for generated headers ... Without using stamp files, meson lists the generated headers as the dependency for every .c file, bloating build.ninja by more than 2x. Processing all the dependencies also increases the time to generate build.ninja. The immediate benefit is that this makes re-configuring and clean builds a bit faster. The main motivation however is that I have other patches that introduce additional build targets that further would increase the size of build.ninja, making re-configuring more noticeably slower. Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/cgkdgvzdpinkacf4v33mky7tbmk467oda5dd4dlmucjjockxzi@xkqfvjoq4uiy	1 month ago
Jacob Champion	4ae03be547	meson: Fix install-quiet after clean ... libpq-oauth was missing from the installed_targets list, so $ ninja clean && ninja install-quiet failed with the error message ERROR: File 'src/interfaces/libpq-oauth/libpq-oauth.a' could not be found It seems a little odd to have to tell Meson what's missing, since it clearly knows how to build that file during regular installation. But the "quiet" variant we've created must use --no-rebuild, to avoid spawning concurrent ninja processes that would step on each other. Reported-by: Andres Freund <andres@anarazel.de> Backpatch-through: 18 Discussion: https://postgr.es/m/hbpqdwxkfnqijaxzgdpvdtp57s7gwxa5d6sbxswovjrournlk6%404jnb2gzan4em	1 month ago
Michael Paquier	1a5212775e	Fix ./configure checks with __cpuidex() and __cpuid() ... The configure checks used two incorrect functions when checking the presence of some routines in an environment: - __get_cpuidex() for the check of __cpuidex(). - __get_cpuid() for the check of __cpuid(). This means that Postgres has never been able to detect the presence of these functions, impacting environments where these exist, like Windows. Simply fixing the function name does not work. For example, using configure with MinGW on Windows causes the checks to detect all four of __get_cpuid(), __get_cpuid_count(), __cpuidex() and __cpuid() to be available, causing a compilation failure as this messes up with the MinGW headers as we would include both <intrin.h> and <cpuid.h>. The Postgres code expects only one in { __get_cpuid() , __cpuid() } and one in { __get_cpuid_count() , __cpuidex() } to exist. This commit reshapes the configure checks to do exactly what meson is doing, which has been working well for us: check one, then the other, but never allow both to be detected in a given build. The logic is wrong since 3dc2d62d04 and 792752af4e where these checks have been introduced (the second case is most likely a copy-pasto coming from the first case), with meson documenting that the configure checks were broken. As far as I can see, they are not once applied consistently with what the code expects, but let's see if the buildfarm has different something to say. The comment in meson.build is adjusted as well, to reflect the new reality. Author: Lukas Fittl <lukas@fittl.com> Co-authored-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/aIgwNYGVt5aRAqTJ@paquier.xyz Backpatch-through: 13	1 month ago
Andres Freund	f54af9f267	aio: Combine io_uring memory mappings, if supported ... By default io_uring creates a shared memory mapping for each io_uring instance, leading to a large number of memory mappings. Unfortunately a large number of memory mappings slows things down, backend exit is particularly affected. To address that, newer kernels (6.5) support using user-provided memory for the memory. By putting the relevant memory into shared memory we don't need any additional mappings. On a system with a new enough kernel and liburing, there is no discernible overhead when doing a pgbench -S -C anymore. Reported-by: MARK CALLAGHAN <mdcallag@gmail.com> Reviewed-by: "Burd, Greg" <greg@burd.me> Reviewed-by: Jim Nasby <jnasby@upgrade.com> Discussion: https://postgr.es/m/CAFbpF8OA44_UG+RYJcWH9WjF7E3GA6gka3gvH6nsrSnEe9H0NA@mail.gmail.com Backpatch-through: 18	2 months ago
Jacob Champion	7376e60854	oauth: Fix kqueue detection on OpenBSD ... In b0635bfda, I added an early header check to the Meson OAuth support, which was intended to duplicate the later checks for HAVE_SYS_[EVENT|EPOLL]_H. However, I implemented the new test via check_header() -- which tries to compile -- rather than has_header(), which just looks for the file's existence. The distinction matters on OpenBSD, where <sys/event.h> can't be compiled without including prerequisite headers, so -Dlibcurl=enabled failed on that platform. Switch to has_header() to fix this. Note that reviewers expressed concern about the difference between our Autoconf feature tests (which compile headers) and our Meson feature tests (which do not). I'm not opposed to aligning the two, but I want to avoid making bigger changes as part of this fix. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/flat/CAOYmi+kdR218ke2zu74oTJvzYJcqV1MN5=mGAPqZQuc79HMSVA@mail.gmail.com Backpatch-through: 18	2 months ago
Peter Eisentraut	f039c22441	meson: Increase minimum version to 0.57.2 ... The previous minimum was to maintain support for Python 3.5, but we now require Python 3.6 anyway (commit 45363fca63), so that reason is obsolete. A small raise to Meson 0.57 allows getting rid of a fair amount of version conditionals and silences some future-deprecated warnings. With the version bump, the following deprecation warnings appeared and are fixed: WARNING: Project targets '>=0.57' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead WARNING: Project targets '>=0.57' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead. It turns out that meson 0.57.0 and 0.57.1 are buggy for our use, so the minimum is actually set to 0.57.2. This is specific to this version series; in the future we won't necessarily need to be this precise. Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org	2 months ago
Peter Eisentraut	8fd9bb1d96	Enable MSVC conforming preprocessor ... Switch MSVC to use the conforming preprocessor, using the /Zc:preprocessor option. This allows us to drop the alternative implementation of VA_ARGS_NARGS() for the previous "traditional" preprocessor. This also prepares the way for enabling C11 mode in the future, which enables the conforming preprocessor by default. This now requires Visual Studio 2019. The installation documentation is adjusted accordingly. Discussion: https://www.postgresql.org/message-id/flat/01a69441-af54-4822-891b-ca28e05b215a%40eisentraut.org	2 months ago
Joe Conway	2652835d3e	Stamp HEAD as 19devel. ... Let the hacking begin ...	2 months ago
Tom Lane	ccd5bc93fd	Include _mm512_zextsi128_si512() in AVX-512 configure probes. ... Commit 43da39430 added a dependency on this intrinsic to our AVX-512 CRC code. It turns out this intrinsic was added to gcc later than the other ones we were using, so that there are platforms where the new code fails to compile. Since only relatively old (pre-gcc-10) compilers are affected, it doesn't seem worth trying to make the AVX-512 CRC code actually work on these platforms. Just add the new intrinsic to the configure probe, so that we'll conclude the code can't be built. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Discussion: https://postgr.es/m/3350336.1750690281@sss.pgh.pa.us	3 months ago
Peter Eisentraut	2c0d8b9508	meson: Fix meson warning ... WARNING: You should add the boolean check kwarg to the run_command call. It currently defaults to false, but it will default to true in meson 2.0. Introduced by commit bc46104fc9. (This only happens in the msvc branch. All the other run_command calls are ok.) Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://www.postgresql.org/message-id/flat/42e13eb0-862a-441e-8d84-4f0fd5f6def0%40eisentraut.org	3 months ago
Tom Lane	12eee85e51	Make our usage of memset_s() conform strictly to the C11 standard. ... Per the letter of the C11 standard, one must #define __STDC_WANT_LIB_EXT1__ as 1 before including <string.h> in order to have access to memset_s(). It appears that many platforms are lenient about this, because we weren't doing it and yet the code appeared to work anyway. But we now find that with -std=c11, macOS is strict and doesn't declare memset_s, leading to compile failures since we try to use it anyway. (Given the lack of prior reports, perhaps this is new behavior in the latest SDK? No matter, we're clearly in the wrong.) In addition to the immediate problem, which could be fixed merely by adding the needed #define to explicit_bzero.c, it seems possible that our configure-time probe for memset_s() could fail in case a platform implements the function in some odd way due to this spec requirement. This concern can be fixed in largely the same way that we dealt with strchrnul() in 6da2ba1d8: switch to using a declaration-based configure probe instead of a does-it-link probe. Back-patch to v13 where we started using memset_s(). Reported-by: Lakshmi Narayana Velayudam <dev.narayana.v@gmail.com> Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/CAA4pTnLcKGG78xeOjiBr5yS7ZeE-Rh=FaFQQGOO=nPzA1L8yEA@mail.gmail.com Backpatch-through: 13	4 months ago
Tom Lane	caa76b91a6	Stamp 18beta1.	4 months ago
Jacob Champion	b0635bfda0	oauth: Move the builtin flow into a separate module ... The additional packaging footprint of the OAuth Curl dependency, as well as the existence of libcurl in the address space even if OAuth isn't ever used by a client, has raised some concerns. Split off this dependency into a separate loadable module called libpq-oauth. When configured using --with-libcurl, libpq.so searches for this new module via dlopen(). End users may choose not to install the libpq-oauth module, in which case the default flow is disabled. For static applications using libpq.a, the libpq-oauth staticlib is a mandatory link-time dependency for --with-libcurl builds. libpq.pc has been updated accordingly. The default flow relies on some libpq internals. Some of these can be safely duplicated (such as the SIGPIPE handlers), but others need to be shared between libpq and libpq-oauth for thread-safety. To avoid exporting these internals to all libpq clients forever, these dependencies are instead injected from the libpq side via an initialization function. This also lets libpq communicate the offsets of PGconn struct members to libpq-oauth, so that we can function without crashing if the module on the search path came from a different build of Postgres. (A minor-version upgrade could swap the libpq-oauth module out from under a long-running libpq client before it does its first load of the OAuth flow.) This ABI is considered "private". The module has no SONAME or version symlinks, and it's named libpq-oauth-<major>.so to avoid mixing and matching across Postgres versions. (Future improvements may promote this "OAuth flow plugin" to a first-class concept, at which point we would need a public API to replace this anyway.) Additionally, NLS support for error messages in b3f0be788a was incomplete, because the new error macros weren't being scanned by xgettext. Fix that now. Per request from Tom Lane and Bruce Momjian. Based on an initial patch by Daniel Gustafsson, who also contributed docs changes. The "bare" dlopen() concept came from Thomas Munro. Many people reviewed the design and implementation; thank you! Co-authored-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Christoph Berg <myon@debian.org> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Wolfgang Walther <walther@technowledgy.de> Discussion: https://postgr.es/m/641687.1742360249%40sss.pgh.pa.us	4 months ago
Tomas Vondra	65c298f61f	Add support for basic NUMA awareness ... Add basic NUMA awareness routines, using a minimal src/port/pg_numa.c portability wrapper and an optional build dependency, enabled by --with-libnuma configure option. For now this is Linux-only, other platforms may be supported later. A built-in SQL function pg_numa_available() allows checking NUMA support, i.e. that the server was built/linked with the NUMA library. The main function introduced is pg_numa_query_pages(), which allows determining the NUMA node for individual memory pages. Internally the function uses move_pages(2) syscall, as it allows batching, and is more efficient than get_mempolicy(2). Author: Jakub Wartak <jakub.wartak@enterprisedb.com> Co-authored-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Tomas Vondra <tomas@vondra.me> Discussion: https://postgr.es/m/CAKZiRmxh6KWo0aqRqvmcoaX2jUxZYb4kGp3N%3Dq1w%2BDiH-696Xw%40mail.gmail.com	5 months ago
John Naylor	3c6e8c1238	Compute CRC32C using AVX-512 instructions where available ... The previous implementation of CRC32C on x86 relied on the native CRC32 instruction from the SSE 4.2 extension, which operates on up to 8 bytes at a time. We can get a substantial speedup by using carryless multiplication on SIMD registers, processing 64 bytes per loop iteration. Shorter inputs fall back to ordinary CRC instructions. On Intel Tiger Lake hardware (2020), CRC is now 50% faster for inputs between 64 and 112 bytes, and 3x faster for 256 bytes. The VPCLMULQDQ instruction on 512-bit registers has been available on Intel hardware since 2019 and AMD since 2022. There is an older variant for 128-bit registers, but at least on Zen 2 it performs worse than normal CRC instructions for short inputs. We must now do a runtime check, even for builds that target SSE 4.2. This doesn't matter in practice for WAL (arguably the most critical case), because since commit e2809e3a1 the final computation with the 20-byte WAL header is inlined and unrolled when targeting that extension. Compared with two direct function calls, testing showed equal or slightly faster performance in performing an indirect function call on several dozen bytes followed by inlined instructions on constant input of 20 bytes. The MIT-licensed implementation was generated with the "generate" program from https://github.com/corsix/fast-crc32/ Based on: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction" V. Gopal, E. Ozturk, et al., 2009 Co-authored-by: Raghuveer Devulapalli <raghuveer.devulapalli@intel.com> Co-authored-by: Paul Amonson <paul.d.amonson@intel.com> Reviewed-by: Nathan Bossart <nathandbossart@gmail.com> Reviewed-by: Andres Freund <andres@anarazel.de> (earlier version) Reviewed-by: Matthew Sterrett <matthewsterrett2@gmail.com> (earlier version) Tested-by: Raghuveer Devulapalli <raghuveer.devulapalli@intel.com> Tested-by: David Rowley <<dgrowleyml@gmail.com>> (earlier version) Discussion: https://postgr.es/m/BL1PR11MB530401FA7E9B1CA432CF9DC3DC192@BL1PR11MB5304.namprd11.prod.outlook.com Discussion: https://postgr.es/m/PH8PR11MB82869FF741DFA4E9A029FF13FBF72@PH8PR11MB8286.namprd11.prod.outlook.com	5 months ago
Daniel Gustafsson	2da74d8d64	libpq: Add support for dumping SSL key material to file ... This adds a new connection parameter which instructs libpq to write out keymaterial clientside into a file in order to make connection debugging with Wireshark and similar tools possible. The file format used is the standardized NSS format. Author: Abhishek Chanda <abhishek.becs@gmail.com> Co-authored-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/CAKiP-K85C8uQbzXKWf5wHQPkuygGUGcufke713iHmYWOe9q2dA@mail.gmail.com	5 months ago
Heikki Linnakangas	09be391126	Add timingsafe_bcmp(), for constant-time memory comparison ... timingsafe_bcmp() should be used instead of memcmp() or a naive for-loop, when comparing passwords or secret tokens, to avoid leaking information about the secret token by timing. This commit just introduces the function but does not change any existing code to use it yet. Co-authored-by: Jelte Fennema-Nio <github-tech@jeltef.nl> Discussion: https://www.postgresql.org/message-id/7b86da3b-9356-4e50-aa1b-56570825e234@iki.fi	5 months ago
Tom Lane	6da2ba1d8a	Fix detection and handling of strchrnul() for macOS 15.4. ... As of 15.4, macOS has strchrnul(), but access to it is blocked behind a check for MACOSX_DEPLOYMENT_TARGET >= 15.4. But our does-it-link configure check finds it, so we try to use it, and fail with the present default deployment target (namely 15.0). This accounts for today's buildfarm failures on indri and sifaka. This is the identical problem that we faced some years ago when Apple introduced preadv and pwritev in the same way. We solved that in commit f014b1b9b by using AC_CHECK_DECLS instead of AC_CHECK_FUNCS to check the functions' availability. So do the same now for strchrnul(). Interestingly, we already had a workaround for "the link check doesn't agree with <string.h>" cases with glibc, which we no longer need since only the header declaration is being checked. Testing this revealed that the meson version of this check has never worked, because it failed to use "-Werror=unguarded-availability-new". (Apparently nobody's tried to build with meson on macOS versions that lack preadv/pwritev as standard.) Adjust that while at it. Also, we had never put support for "-Werror=unguarded-availability-new" into v13, but we need that now. Co-authored-by: Tom Lane <tgl@sss.pgh.pa.us> Co-authored-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/385134.1743523038@sss.pgh.pa.us Backpatch-through: 13	5 months ago
Nathan Bossart	519338ace4	Optimize popcount functions with ARM SVE intrinsics. ... This commit introduces SVE implementations of pg_popcount{32,64}. Unlike the Neon versions, we need an additional configure-time check to determine if the compiler supports SVE intrinsics, and we need a runtime check to determine if the current CPU supports SVE instructions. Our testing showed that the SVE implementations are much faster for larger inputs and are comparable to the status quo for smaller inputs. Author: "Devanga.Susmitha@fujitsu.com" <Devanga.Susmitha@fujitsu.com> Co-authored-by: "Chiranmoy.Bhattacharya@fujitsu.com" <Chiranmoy.Bhattacharya@fujitsu.com> Co-authored-by: "Malladi, Rama" <ramamalladi@hotmail.com> Reviewed-by: John Naylor <johncnaylorls@gmail.com> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Discussion: https://postgr.es/m/010101936e4aaa70-b474ab9e-b9ce-474d-a3ba-a3dc223d295c-000000%40us-west-2.amazonses.com Discussion: https://postgr.es/m/OSZPR01MB84990A9A02A3515C6E85A65B8B2A2%40OSZPR01MB8499.jpnprd01.prod.outlook.com	6 months ago
Peter Eisentraut	3c8e463b0d	Revert "Tidy up locale thread safety in ECPG library." ... This reverts commit 8e993bff53. It causes various build failures on the buildfarm, to be investigated. Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech	6 months ago
Peter Eisentraut	8e993bff53	Tidy up locale thread safety in ECPG library. ... Remove setlocale() and _configthreadlocal() as fallback strategy on systems that don't have uselocale(), where ECPG tries to control LC_NUMERIC formatting on input and output of floating point numbers. It was probably broken on some systems (NetBSD), and the code was also quite messy and complicated, with obsolete configure tests (Windows). It was also arguably broken, or at least had unstated environmental requirements, if pgtypeslib code was called directly. Instead, introduce PG_C_LOCALE to refer to the "C" locale as a locale_t value. It maps to the special constant LC_C_LOCALE when defined by libc (macOS, NetBSD), or otherwise uses a process-lifetime locale_t that is allocated on first use, just as ECPG previously did itself. The new replacement might be more widely useful. Then change the float parsing and printing code to pass that to _l() functions where appropriate. Unfortunately the portability of those functions is a bit complicated. First, many obvious and useful _l() functions are missing from POSIX, though most standard libraries define some of them anyway. Second, although the thread-safe save/restore technique can be used to replace the missing ones, Windows and NetBSD refused to implement standard uselocale(). They might have a point: "wide scope" uselocale() is hard to combine with other code and error-prone, especially in library code. Luckily they have the _l() functions we want so far anyway. So we have to be prepared for both ways of doing things: 1. In ECPG, use strtod_l() for parsing, and supply a port.h replacement using uselocale() over a limited scope if missing. 2. Inside our own snprintf.c, use three different approaches to format floats. For frontend code, call libc's snprintf_l(), or wrap libc's snprintf() in uselocale() if it's missing. For backend code, snprintf.c can keep assuming that the global locale's LC_NUMERIC is "C" and call libc's snprintf() without change, for now. (It might eventually be possible to call our in-tree Ryū routines to display floats in snprintf.c, given the C-locale-always remit of our in-tree snprintf(), but this patch doesn't risk changing anything that complicated.) Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Tristan Partin <tristan@partin.io> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech	6 months ago
Peter Eisentraut	b98be8a2a2	Provide thread-safe pg_localeconv_r(). ... This involves four different implementation strategies: 1. For Windows, we now require _configthreadlocale() to be available and work (commit f1da075d9a), and the documentation says that the object returned by localeconv() is in thread-local memory. 2. For glibc, we translate to nl_langinfo_l() calls, because it offers the same information that way as an extension, and that API is thread-safe. 3. For macOS/*BSD, use localeconv_l(), which is thread-safe. 4. For everything else, use uselocale() to set the locale for the thread, and use a big ugly lock to defend against the returned object being concurrently clobbered. In practice this currently means only Solaris. The new call is used in pg_locale.c, replacing calls to setlocale() and localeconv(). Author: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CA%2BhUKGJqVe0%2BPv9dvC9dSums_PXxGo9SWcxYAMBguWJUGbWz-A%40mail.gmail.com	6 months ago
Andres Freund	8eadd5c73c	aio: Add liburing dependency ... Will be used in a subsequent commit, to implement io_method=io_uring. Kept separate for easier review. Reviewed-by: Noah Misch <noah@leadboat.com> Discussion: https://postgr.es/m/uvrtrknj4kdytuboidbhwclo4gxhswwcpgadptsjvjqcluzmah%40brqs62irg4dt	6 months ago
Andrew Dunstan	12604593e9	Show plperl version in the meson setup summary. ... Also, use perl 'version' instead of 'api_versionstring' to sync with the configure script. Author: Roman Zharkov <r.zharkov@postgrespro.ru> Discussion: https://postgr.es/m/93e7f77bf4e1ef4640e4ee733f9e2a78@postgrespro.ru	6 months ago
Tom Lane	fdb5dd6331	Be more paranoid in configure's checks for CRC and POPCNT intrinsics. ... In these tests, we need to verify not only that the compiler has heard of these intrinsics, but that lower-level tools cope with them too. (For example, the assembler must also know the instructions, and on some platforms there might be library support involved.) The hazard is that the compiler might optimize away the calls altogether, allowing the configure check to succeed only to have the build fail later if lower-level support is missing. The existing code tried to prevent that by ensuring that the result of the intrinsic is used for something, but that's really insufficient because we were feeding constant input to it. So the compiler would be perfectly entitled to optimize away the calls anyway. Fix by making the inputs into global variables. (Hypothetically, LTO optimization could still remove the code --- but that's well past where we'd be likely to hit trouble.) It is not known that any current compiler would actually optimize away these calls, and even if that happened it would be unlikely that any problem would manifest. Our concern for this stems from largely-bygone days when it was common to install gcc on platforms with some other native compiler, so that a compiler-vs-library support discrepancy was more probable. Still, there's little point in defending against such cases in a way that is visibly incomplete. I'm content to fix this in master for now; we can back-patch if any indication appears that it's a live problem for someone. Discussion: https://postgr.es/m/3368102.1741993462@sss.pgh.pa.us	6 months ago
Thomas Munro	d7e40845f9	oauth: Disallow synchronous DNS in libcurl ... There is concern that a blocking DNS lookup in libpq could stall a backend process (say, via FDW). Since there's currently no strong evidence that synchronous DNS is a popular option, disallow it entirely rather than warning at configure time. We can revisit if anyone complains. Per query from Andres Freund. Author: Jacob Champion <jacob.champion@enterprisedb.com> Discussion: https://postgr.es/m/p4bd7mn6dxr2zdak74abocyltpfdxif4pxqzixqpxpetjwt34h%40qc6jgfmoddvq	6 months ago
Andres Freund	32ce58e9e9	Make test portlock logic work with meson ... Previously the portlock logic, added in 9b4eafcaf4, didn't actually work properly when the tests were run via meson. 9b4eafcaf4 used the MESON_BUILD_ROOT environment variable to determine the directory for the port lock directory, but that's never set for running the tests. That meant that each test used its own portlock dir, unless the PG_TEST_PORT_DIR environment variable was set. Fix the problem by setting top_builddir for the environment. That's also used for the autoconf/make build. Backpatch back to 16, where meson support was added. Reported-by: Zharkov Roman <r.zharkov@postgrespro.ru> Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Backpatch-through: 16	7 months ago
Daniel Gustafsson	b3f0be788a	Add support for OAUTHBEARER SASL mechanism ... This commit implements OAUTHBEARER, RFC 7628, and OAuth 2.0 Device Authorization Grants, RFC 8628. In order to use this there is a new pg_hba auth method called oauth. When speaking to a OAuth- enabled server, it looks a bit like this: $ psql 'host=example.org oauth_issuer=... oauth_client_id=...' Visit https://oauth.example.org/login and enter the code: FPQ2-M4BG Device authorization is currently the only supported flow so the OAuth issuer must support that in order for users to authenticate. Third-party clients may however extend this and provide their own flows. The built-in device authorization flow is currently not supported on Windows. In order for validation to happen server side a new framework for plugging in OAuth validation modules is added. As validation is implementation specific, with no default specified in the standard, PostgreSQL does not ship with one built-in. Each pg_hba entry can specify a specific validator or be left blank for the validator installed as default. This adds a requirement on libcurl for the client side support, which is optional to build, but the server side has no additional build requirements. In order to run the tests, Python is required as this adds a https server written in Python. Tests are gated behind PG_TEST_EXTRA as they open ports. This patch has been a multi-year project with many contributors involved with reviews and in-depth discussions: Michael Paquier, Heikki Linnakangas, Zhihong Yu, Mahendrakar Srinivasarao, Andrey Chudnovsky and Stephen Frost to name a few. While Jacob Champion is the main author there have been some levels of hacking by others. Daniel Gustafsson contributed the validation module and various bits and pieces; Thomas Munro wrote the client side support for kqueue. Author: Jacob Champion <jacob.champion@enterprisedb.com> Co-authored-by: Daniel Gustafsson <daniel@yesql.se> Co-authored-by: Thomas Munro <thomas.munro@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Reviewed-by: Antonin Houska <ah@cybertec.at> Reviewed-by: Kashif Zeeshan <kashi.zeeshan@gmail.com> Discussion: https://postgr.es/m/d1b467a78e0e36ed85a09adf979d04cf124a9d4b.camel@vmware.com	7 months ago
Andres Freund	b64d83115c	meson: Fix failure to detect bsd_auth.h presence ... bsd_auth.h file needs to be included after 'sys/types.h', as documented in https://man.openbsd.org/authenticate.3 The reason a similar looking stanza works for autoconf is that autoconf automatically adds AC_INCLUDES_DEFAULT, which in turn includes sys/types.h. Backpatch to all versions with meson support. Author: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/637haqqyhg2wlz7q6wq25m2qupe67g7f2uupngzui64zypy4x2@ysr2xnmynmu4 Backpatch-through: 16	7 months ago
Andres Freund	26aca4de43	meson: Add missing dependencies for libpq tests ... The missing dependency was, e.g., visible when doing ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite libpq This is a bit more complicated than other related fixes, because until now libpq's tests depended on 'frontend_code', which includes a dependency on fe_utils, which in turns on libpq. That in turn required src/interfaces/libpq/test to be entered from the top-level, not from libpq/meson.build. Because of that the test definitions in libpq/meson.build could not declare a dependency on the binaries defined in libpq/test/meson.build. To fix this, this commit creates frontend_no_fe_utils_code, which allows us to recurse into libpq/test from withing libpq/meson.build. Apply this to all branches with meson support, as part of an effort to fix incorrect test dependencies that can lead to test failures. Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org Backpatch: 16-, where meson support was added	7 months ago
Andres Freund	74ef4855b0	meson: Improve dependencies for tmp_install test target ... The missing dependency was, e.g., visible when doing ninja clean && ninja meson-test-prereq && meson test --no-rebuild --suite setup --suite cube because meson (and thus its internal meson-test-prereq target) did not know about a lot of the required targets. Previously tmp_install did not actually depend on the relevant files being built. That was mostly not visible, because "meson test" currently uses the 'default' targets as a test's dependency if no dependency is specified. However, there are plans to narrow that on the meson side, to make it quicker to run tests. Apply this to all branches with meson support, as part of an effort to fix incorrect test dependencies that can lead to test failures. Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org Backpatch: 16-, where meson support was added	7 months ago
Andres Freund	c2ede6640c	meson: Narrow dependencies for 'install-quiet' target ... Previously test dependencies, which are not actually installed, were unnecessarily built. Apply this to all branches with meson support, as part of an effort to fix incorrect test dependencies that can lead to test failures. Discussion: https://postgr.es/m/CAGECzQSvM3iSDmjF+=Kof5an6jN8UbkP_4cKKT9w6GZavmb5yQ@mail.gmail.com Discussion: https://postgr.es/m/bdba588f-69a9-4f3e-9b95-62d07210a32e@eisentraut.org Backpatch: 16-, where meson support was added	7 months ago
Peter Eisentraut	aeb8ea361a	Convert sepgsql tests to TAP ... Add a TAP test for sepgsql. This automates the previously required manual setup before the test. The actual tests are still run by pg_regress, as before, but now called from within the TAP Perl script. The previous manual test script (test_sepgsql) is left in place, since its purpose is (also) to test whether a running instance was properly initialized for sepgsql. But it has been changed to call pg_regress directly and no longer require make. Reviewed-by: Andreas Karlsson <andreas@proxel.se> Discussion: https://www.postgresql.org/message-id/flat/651a5baf-5c45-4a5a-a202-0c8453a4ebf8@eisentraut.org	8 months ago
Peter Eisentraut	0869ea43e9	Remove flex version checks ... Remove the flex version checks from configure and meson. The cutoff versions are all so ancient that this is no longer relevant, and what the actual cutoff should be is a bit fuzzy. This also removes the ancient behavior that configure would also accept a "lex" program if it is actuall flex. This aligns the check with meson in this respect. For future reference, as of this commit, these are relevant flex versions: - The hard required minimum is flex 2.5.34 as of commit b1ef48980d, but this has not actually been tested. - Prior to this, the minimum enforced by configure/meson was flex 2.5.35, which is the oldest present in the buildfarm right now. - As of commit 6fdd5d9563, the oldest version that will compile without warnings due to flex-generated code is flex 2.5.36. - The oldest version that probably still has some practical relevance is flex 2.5.37, which ships with CentOS/RHEL 7. Discussion: https://www.postgresql.org/message-id/1a204ccd-7ae6-478c-a431-407b5c48ccc6@eisentraut.org	8 months ago
Thomas Munro	c4782c4410	Fix meson detection of a couple of 64 bit builtins. ... A couple of checks were missed by commit 962da900, so we would fail to detect the features. Reported-by: Юрий Соколов <y.sokolov@postgrespro.ru> Discussion: https://postgr.es/m/42C25E2A-6519-4549-9F47-6B0686E83836%40postgrespro.ru	8 months ago
Peter Eisentraut	9a8313dabe	Remove useless configure check ... The test for "decltype" as a variant of "typeof" apparently never worked (see also commit 3582b223d4), so remove it. Discussion: https://www.postgresql.org/message-id/flat/795b1c54-c64a-47f9-8fa3-880dcab59975%40eisentraut.org	8 months ago
Peter Eisentraut	6549a02a51	meson: Fix missing name arguments of cc.compiles() calls ... Without it, the check won't show up in the meson setup/configure output. Discussion: https://www.postgresql.org/message-id/flat/795b1c54-c64a-47f9-8fa3-880dcab59975%40eisentraut.org	8 months ago
Bruce Momjian	50e6eb731d	Update copyright for 2025 ... Backpatch-through: 13	8 months ago
Thomas Munro	962da900ac	Use <stdint.h> and <inttypes.h> for c.h integers. ... Redefine our exact width types with standard C99 types and macros, including int64_t, INT64_MAX, INT64_C(), PRId64 etc. We were already using <stdint.h> types in a few places. One complication is that Windows' <inttypes.h> uses format strings like "%I64d", "%I32", "%I" for PRI*64, PRI*32, PTR*PTR, instead of mapping to other standardized format strings like "%lld" etc as seen on other known systems. Teach our snprintf.c to understand them. This removes a lot of configure clutter, and should also allow 64-bit numbers and other standard types to be used in localized messages without casting. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/ME3P282MB3166F9D1F71F787929C0C7E7B6312%40ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM	9 months ago
Tom Lane	3b08d5224d	Define __EXTENSIONS__ on Solaris, too. ... Apparently, if you define _POSIX_C_SOURCE on Solaris, that's interpreted as "you get ONLY what's defined by POSIX". Results from BF member hake show that that breaks perl.h, and doubtless it'd cause more problems if we got past that. Adopt the suggestion from standards(7) that we also need to define __EXTENSIONS__, in hopes of un-breaking things. Discussion: https://postgr.es/m/1654508.1733162761@sss.pgh.pa.us	9 months ago
Tom Lane	32a7deb2a0	Define _POSIX_C_SOURCE as 200112L on Solaris. ... This is an attempt to suppress some compiler warnings that appeared in the wake of commit 7f798aca1: it seems that by default Solaris/illumos declares shmdt() to take "char *" not "void *". We'd like the system headers to provide modern POSIX APIs, and POSIX 2001 seems to be as modern as is available there. illumos' standards(7) man page suggests that we might also need to define __EXTENSIONS__, but let's see what happens with just this. Discussion: https://postgr.es/m/1654508.1733162761@sss.pgh.pa.us	9 months ago
Thomas Munro	97525bc5c8	Require sizeof(bool) == 1. ... The C standard says that sizeof(bool) is implementation-defined, but we know of no current systems where it is not 1. The last known systems seem to have been Apple macOS/PowerPC 10.5 and Microsoft Visual C++ 4, both long defunct. PostgreSQL has always required sizeof(bool) == 1 for the definition of bool that it used, but previously it would define its own type if the system-provided bool had a different size. That was liable to cause memory layout problems when interacting with system and third-party libraries on (by now hypothetical) computers with wider _Bool, and now C23 has introduced a new problem by making bool a built-in datatype (like C++), so the fallback code doesn't even compile. We could probably work around that, but then we'd be writing new untested code for a computer that doesn't exist. Instead, delete the unreachable and C23-uncompilable fallback code, and let existing static assertions fail if the system-provided bool is too wide. If we ever get a problem report from a real system, then it will be time to figure out what to do about it in a way that also works on modern compilers. Note on C++: Previously we avoided including <stdbool.h> or trying to define a new bool type in headers that might be included by C++ code. These days we might as well just include <stdbool.h> unconditionally: it should be visible to C++11 but do nothing, just as in C23. We already include <stdint.h> without C++ guards in c.h, and that falls under the same C99-compatibility section of the C++11 standard as <stdbool.h>, so let's remove the guards here too. Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3198438.1731895163%40sss.pgh.pa.us	10 months ago
Nathan Bossart	4b03a27faf	Use __attribute__((target(...))) for SSE4.2 CRC-32C support. ... Presently, we check for compiler support for the required intrinsics both with and without the -msse4.2 compiler flag, and then depending on the results of those checks, we pick which files to compile with which flags. This is tedious and complicated, and it results in unsustainable coding patterns such as separate files for each portion of code that may need to be built with different compiler flags. This commit makes use of the newly-added support for __attribute__((target(...))) in the SSE4.2 CRC-32C code. This simplifies both the configure-time checks and the build scripts, and it allows us to place the functions that use the intrinsics in files that we otherwise do not want to build with special CPU instructions (although this commit refrains from doing so). This is also preparatory work for a proposed follow-up commit that will further optimize the CRC-32C code with AVX-512 instructions. While at it, this commit modifies meson's checks for SSE4.2 CRC support to be the same as autoconf's. meson was choosing whether to use a runtime check based purely on whether -msse4.2 is required, while autoconf has long checked for the __SSE4_2__ preprocessor symbol to decide. meson's previous approach seems to work just fine, but this change avoids needing to build multiple test programs and to keep track of whether to actually use pg_attribute_target(). Ideally we'd use __attribute__((target(...))) for ARMv8 CRC support, too, but there's little point in doing so because until clang 16, using the ARM intrinsics still requires special compiler flags. Perhaps we can re-evaluate this decision after some time has passed. Author: Raghuveer Devulapalli Discussion: https://postgr.es/m/PH8PR11MB8286BE735A463468415D46B5FB5C2%40PH8PR11MB8286.namprd11.prod.outlook.com	10 months ago
Thomas Munro	f1da075d9a	Remove configure check for _configthreadlocale(). ... All modern Windows systems have _configthreadlocale(). It was first introduced in msvcr80.dll from Visual Studio 2005. Historically, MinGW was stuck on even older msvcrt.dll, but added its own dummy implementation of the function when using msvcrt.dll years ago anyway, effectively rendering the configure test useless. In practice we don't encounter the dummy anymore because modern MinGW uses ucrt. Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/CWZBBRR6YA8D.8EHMDRGLCKCD%40neon.tech	10 months ago
Thomas Munro	648333a99f	Clean up <stdbool.h> reference in meson.build. ... Commit bc5a4dfc accidentally left a check for <stdbool.h> in meson.build's header_checks. Synchronize with configure, which no longer defines HAVE_STDBOOL_H. There is still a reference to <stdbool.h> in an earlier test to see if we need -std=c99 to get C99 features, like autoconf 2.69's AC_PROG_CC_C99. (Therefore the test remove by this commit was tautological since day one: you'd have copped "C compiler does not support C99" before making it this far.) Back-patch to 16, where meson begins.	10 months ago
Tom Lane	5980f1884f	Update configure probes for CFLAGS needed for ARM CRC instructions. ... On ARM platforms where the baseline CPU target lacks CRC instructions, we need to supply a -march flag to persuade the compiler to compile such instructions. It turns out that our existing choice of "-march=armv8-a+crc" has not worked for some time, because recent gcc will interpret that as selecting software floating point, and then will spit up if the platform requires hard-float ABI, as most do nowadays. The end result was to silently fall back to software CRC, which isn't very desirable since in practice almost all currently produced ARM chips do have hardware CRC. We can fix this by using "-march=armv8-a+crc+simd" to enable the correct ABI choice. (This has no impact on the code actually generated, since neither of the files we compile with this flag does any floating-point stuff, let alone SIMD.) Keep the test for "-march=armv8-a+crc" since that's required for soft-float ABI, but try that second since most platforms we're likely to build on use hard-float. Since this isn't working as-intended on the last several years' worth of gcc releases, back-patch to all supported branches. Discussion: https://postgr.es/m/4496616.iHFcN1HehY@portable-bastien	10 months ago
Thomas Munro	bc5a4dfcf7	Assume that <stdbool.h> conforms to the C standard. ... Previously we checked "for <stdbool.h> that conforms to C99" using autoconf's AC_HEADER_STDBOOL macro. We've required C99 since PostgreSQL 12, so the test was redundant, and under C23 it was broken: autoconf 2.69's implementation doesn't understand C23's new empty header (the macros it's looking for went away, replaced by language keywords). Later autoconf versions fixed that, but let's just remove the anachronistic test. HAVE_STDBOOL_H and HAVE__BOOL will no longer be defined, but they weren't directly tested in core or likely extensions (except in 11, see below). PG_USE_STDBOOL (or USE_STDBOOL in 11 and 12) is still defined when sizeof(bool) is 1, which should be true on all modern systems. Otherwise we define our own bool type and values of size 1, which would fail to compile under C23 as revealed by the broken test. (We'll probably clean that dead code up in master, but here we want a minimal back-patchable change.) This came to our attention when GCC 15 recently started using using C23 by default and failed to compile the replacement code, as reported by Sam James and build farm animal alligator. Back-patch to all supported releases, and then two older versions that also know about <stdbool.h>, per the recently-out-of-support policy[1]. 12 requires C99 so it's much like the supported releases, but 11 only assumes C89 so it now uses AC_CHECK_HEADERS instead of the overly picky AC_HEADER_STDBOOL. (I could find no discussion of which historical systems had <stdbool.h> but failed the conformance test; if they ever existed, they surely aren't relevant to that policy's goals.) [1] https://wiki.postgresql.org/wiki/Committing_checklist#Policies Reported-by: Sam James <sam@gentoo.org> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> (master version) Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> (approach) Discussion: https://www.postgresql.org/message-id/flat/87o72eo9iu.fsf%40gentoo.org	10 months ago