postgresql.git/src/include/libpq, branch master

Fix REPACK worker startup and shutdown sequences

2026-09-17T09:44:57Z

A REPACK background worker can fail to start for various reasons, but the REPACK steering process was not handling them correctly. For instance, the steering process waits on a condition variable, but it would simply hang if the worker doesn't send the signal. (A signal would be sent by postmaster, but it would wake up the process only to be ignored and continue sleeping.) Fix this by splitting the wait in two: first wait for the worker to attach to the error queue, and then wait on the condition variable as before. The shutdown sequence can also get stuck, if the message queue gets full while trying to shut down (this can apparently happen if the log level is set to very noisy). Previously the worker would send a signal and then detach; but the steering process can receive that signal, act on it, then fail to wake up to handle the detach, sleeping indefinitely. Fix this by having the worker send a Terminate message, which the steering process can react to. Author: Bharath Rupireddy Author: Shihao Zhong Author: Álvaro Herrera Reviewed-by: Antonin Houska Reviewed-by: Masahiko Sawada Reviewed-by: Shihao Zhong Reported-by: Nathan Bossart Reported-by: Bharath Rupireddy Reported-by: Nikolay Samokhvalov Backpatch-through: 19 Discussion: https://postgr.es/m/CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz%3DkuQdZBeLrod0gqUxH3g%40mail.gmail.com Discussion: https://postgr.es/m/apBpOVZOyqrakEr_@nathan

Rename PqMsg_Progress to PqParallelMsg_Progress.

2026-09-10T20:10:35Z

The previous name was considered to be unduly generic. This commit addresses that by adding a new "PqParallelMsg" prefix for protocol characters sent by parallel workers to leader processes. The new prefix can be reused for new parallel worker message types added in the future. Author: Sami Imseih Reviewed-by: Tom Lane Reviewed-by: Kirill Reshke Reviewed-by: Antonin Houska Discussion: https://postgr.es/m/CAN12%2BYLqbiA1v3FPD94yLbXgdyoWxVEY6%3DDtdpTPo9YCRuCpfg%40mail.gmail.com

Set notice receiver before libpq connection startup completes

2026-05-22T15:25:48Z

Commit 112faf1378e added custom notice receivers for replication, postgres_fdw, and dblink so that remote NOTICE, WARNING, and similar messages are reported via ereport(). However, those notice receivers were installed only after libpqsrv_connect() and libpqsrv_connect_params() returned, by which point libpq connection startup had already completed. As a result, messages emitted during connection establishment could be missed. This commit fixes the issue by splitting libpqsrv_connect() and libpqsrv_connect_params() into separate start and complete phases: libpqsrv_connect_start(), libpqsrv_connect_params_start(), and libpqsrv_connect_complete(). This allows callers to perform per-connection setup, such as installing a notice receiver, after the connection has been started but before startup completes. Note that callers of libpqsrv_connect_start() and libpqsrv_connect_params_start() must still call libpqsrv_connect_complete(), even if the start function returns NULL, so that any external FDs reserved during startup are released properly. Author: Chao Li Reviewed-by: Fujii Masao Reviewed-by: Vignesh C Reviewed-by: Rafia Sabih Discussion: https://postgr.es/m/A2B8B7DE-C119-492F-A9FA-14CF86849777@gmail.com

Pre-beta mechanical code beautification, step 1: run pgindent.

2026-05-13T14:34:17Z

Update typedefs.list from the buildfarm, and run pgindent. The changes from the new typedefs list are pretty minimal, since we'd been pretty good (not perfect) about updating typedefs.list by hand. But the pgindent behavior changes installed by a3e6beba6, b518ba4af, and 60f9467c3 add up to make this a relatively sizable diff.

Declare load_hosts() as returning HostsFileLoadResult.

2026-05-04T22:33:06Z

This function returns some value of enum HostsFileLoadResult, but for reasons lost in the development process was declared to return "int". Fix that, for clarity and so that our typedefs collection tooling sees the typedef as used. Also fix the variable that the sole call assigns into. Move the typedef to the header file that declares load_hosts() to avoid creating header dependency problems. Discussion: https://postgr.es/m/359138.1777922557@sss.pgh.pa.us

Remove RADIUS support.

2026-04-08T10:38:43Z

Our RADIUS implementation supported only the deprecated RADIUS/UDP variant, without the recommended Message-Authenticator attribute to mitigate against the Blast-RADIUS vulnerability. By now, popular RADIUS servers are expected to generate loud warnings or reject our authentication attempts outright. Since there have been no user reports about this, it seems unlikely that there are users. Reviewed-by: Álvaro Herrera Reviewed-by: Aleksander Alekseev Reviewed-by: Tom Lane Reviewed-by: Jacob Champion Reviewed-by: Michael Banck Discussion: https://postgr.es/m/CA%2BhUKG%2BSH309V8KECU5%3DxuLP9Dks0v9f9UVS2W74fPAE5O21dg%40mail.gmail.com

oauth: Allow validators to register custom HBA options

2026-04-07T15:15:19Z

OAuth validators can already use custom GUCs to configure behavior globally. But we currently provide no ability to adjust settings for individual HBA entries, because the original design focused on a world where a provider covered a "single audience" of users for one database cluster. This assumption does not apply to multitenant use cases, where a single validator may be controlling access for wildly different user groups. To improve this use case, add two new API calls for use by validator callbacks: RegisterOAuthHBAOptions() and GetOAuthHBAOption(). Registering options "foo" and "bar" allows a user to set "validator.foo" and "validator.bar" in an oauth HBA entry. These options are stringly typed (syntax validation is solely the responsibility of the defining module), and names are restricted to a subset of ASCII to avoid tying our hands with future HBA syntax improvements. Unfortunately, we can't check the custom option names during a reload of the configuration, like we do with standard HBA options, without requiring all validators to be loaded via shared_preload_libraries. (I consider this to be a nonstarter: most validators should probably use session_preload_libraries at most, since requiring a full restart just to update authentication behavior will be unacceptable to many users.) Instead, the new validator.* options are checked against the registered list at connection time. Multiple alternatives were proposed and/or prototyped, including extending the GUC system to allow per-HBA overrides, joining forces with recent refactoring work on the reloptions subsystem, and giving the ability to customize HBA options to all PostgreSQL extensions. I personally believe per-HBA GUC overrides are the best option, because several existing GUCs like authentication_timeout and pre_auth_delay would fit there usefully. But the recent addition of SNI per-host settings in 4f433025f indicates that a more general solution is needed, and I expect that to take multiple releases' worth of discussion. This compromise patch, then, is intentionally designed to be an architectural dead end: simple to describe, cheap to maintain, and providing just enough functionality to let validators move forward for PG19. The hope is that it will be replaced in the future by a solution that can handle per-host, per-HBA, and other per-context configuration with the same functionality that GUCs provide today. In the meantime, the bulk of the code in this patch consists of strict guardrails on the simple API, to try to ensure that we don't have any reason to regret its existence during its unknown lifespan. I owe particular thanks here to Zsolt Parragi, who prototyped several approaches that guided the final design. Suggested-by: Zsolt Parragi Suggested-by: VASUKI M Reviewed-by: Zsolt Parragi Discussion: https://postgr.es/m/CAN4CZFM3b8u5uNNNsY6XCya257u%2BDofms3su9f11iMCxvCacag%40mail.gmail.com

oauth: Let validators provide failure DETAILs

2026-04-03T23:05:33Z

At the moment, the only way for a validator module to report error details on failure is to log them separately before returning from validate_cb. Independently of that problem, the ereport() calls that we make during validation failure partially duplicate some of the work of auth_failed(). The end result is overly verbose and confusing for readers of the logs: [768233] LOG: [my_validator] bad signature in bearer token [768233] LOG: OAuth bearer authentication failed for user "jacob" [768233] DETAIL: Validator failed to authorize the provided token. [768233] FATAL: OAuth bearer authentication failed for user "jacob" [768233] DETAIL: Connection matched file ".../pg_hba.conf" line ... Solve both problems by making use of the existing logdetail pointer that's provided by ClientAuthentication. Validator modules may set ValidatorModuleResult->error_detail to override our default generic message. The end result looks something like [242284] FATAL: OAuth bearer authentication failed for user "jacob" [242284] DETAIL: [my_validator] bad signature in bearer token Connection matched file ".../pg_hba.conf" line ... Reported-by: Álvaro Herrera Reported-by: Zsolt Parragi Reviewed-by: Chao Li Reviewed-by: Daniel Gustafsson Reviewed-by: Zsolt Parragi Discussion: https://postgr.es/m/202601241015.y5uvxd7oxnfs%40alvherre.pgsql

sasl: Allow backend mechanisms to "abandon" exchanges

2026-03-31T18:47:31Z

Introduce PG_SASL_EXCHANGE_ABANDONED, which allows CheckSASLAuth to suppress the failing log entry for any SASL exchange that isn't actually an authentication attempt. This is desirable for OAUTHBEARER's discovery exchanges (and a subsequent commit will make use of it there). This might have some overlap in the future with in-band aborts for SASL exchanges, but it's intentionally not named _ABORTED to avoid confusion. (We don't currently support clientside aborts in our SASL profile.) Adapted from a patch by Zsolt Parragi. Author: Zsolt Parragi Co-authored-by: Jacob Champion Reviewed-by: Chao Li Discussion: https://postgr.es/m/CAN4CZFPim7hUiyb7daNKQPSZ8CvQRBGkVhbvED7yZi8VktSn4Q%40mail.gmail.com

ssl: Serverside SNI support for libpq

2026-03-18T11:37:11Z

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