postgresql.git/src/interfaces, branch master

Pre-beta mechanical code beautification, step 2: run pgperltidy.

2026-05-13T14:37:42+00:00

It's as opinionated as ever.

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

2026-05-13T14:34:17+00:00

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.

Mark PQfn() unsafe and fix overrun in frontend LO interface.

2026-05-11T12:13:47+00:00

When result_is_int is set to 0, PQfn() cannot validate that the result fits in result_buf, so it will write data beyond the end of the buffer when the server returns more data than requested. Since this function is insecurable and obsolete, add a warning to the top of the pertinent documentation advising against its use. The only in-tree caller of PQfn() is the frontend large object interface. To fix that, add a buf_size parameter to pqFunctionCall3() that is used to protect against overruns, and use it in a private version of PQfn() that also accepts a buf_size parameter. Reported-by: Yu Kunpeng Reported-by: Martin Heistermann Author: Nathan Bossart Reviewed-by: Noah Misch Reviewed-by: Tom Lane Reviewed-by: Etsuro Fujita Security: CVE-2026-6477 Backpatch-through: 14

Apply timingsafe_bcmp() in authentication paths

2026-05-11T12:13:46+00:00

This commit applies timingsafe_bcmp() to authentication paths that handle attributes or data previously compared with memcpy() or strcmp(), which are sensitive to timing attacks. The following data is concerned by this change, some being in the backend and some in the frontend: - For a SCRAM or MD5 password, the computed key or the MD5 hash compared with a password during a plain authentication. - For a SCRAM exchange, the stored key, the client's final nonce and the server nonce. - RADIUS (up to v18), the encrypted password. - For MD5 authentication, the MD5(MD5()) hash. Reported-by: Joe Conway Security: CVE-2026-6478 Author: Michael Paquier Reviewed-by: John Naylor Backpatch-through: 14

Message style improvements (oauth related)

2026-05-05T08:39:13+00:00

Add missing connection validation in ECPG

2026-05-01T19:12:28+00:00

ECPGdeallocate_all(), ECPGprepared_statement(), ECPGget_desc(), and ecpg_freeStmtCacheEntry() could crash with a SIGSEGV when called without an established connection (for example, when EXEC SQL CONNECT was forgotten or a non-existent connection name was used), because they dereferenced the result of ecpg_get_connection() without first checking it for NULL. Each site is fixed in the style of the surrounding code. New tests are added for these conditions. Author: Shruthi Gowda Reviewed-by: Tom Lane Reviewed-by: Fujii Masao Reviewed-by: Mahendra Singh Thalor Reviewed-by: Nishant Sharma Discussion: https://postgr.es/m/3007317.1765210195@sss.pgh.pa.us Backpatch-through: 14

Fix a set of typos and grammar issues across the tree

2026-04-21T05:46:22+00:00

This batch is similar to 462fe0ff6215 and addresses a variety of code style issues, including grammar mistakes, typos, inconsistent variable names in function declarations, and incorrect function names in comments and documentation. These fixes have accumulated on the community mailing lists since the commit mentioned above. Notably, Alexander Lakhin previously submitted a patch identifying many of the trivial typos and grammar issues that had been reported on pgsql-hackers. His patch covered a somewhat large portion of the issues addressed here, though not all of them. The documentation changes only affect HEAD.

Rework signal handler infrastructure to pass sender info as argument.

2026-04-15T11:30:34+00:00

Commit 095c9d4cf06 added errdetail() reporting of the PID and UID of the process that sent a termination signal. However, as noted by Andres Freund, the implementation had architectural problems: 1. wrapper_handler() in pqsignal.c contained SIGTERM-specific logic (setting ProcDieSenderPid/Uid), violating its role as a generic signal dispatch wrapper. 2. Using globals to pass sender info between wrapper_handler and the real handler is unsafe when signals nest on some platforms. 3. The syncrep.c errdetail used psprintf() to conditionally embed text via %s, breaking translatability. Adopt the approach proposed by Andres Freund: introduce a pg_signal_info struct that is passed as an argument to all signal handlers via the SIGNAL_ARGS macro. wrapper_handler populates it from siginfo_t when SA_SIGINFO is available, or with zeros otherwise. This keeps wrapper_handler fully generic and avoids any globals for passing signal metadata. Since pqsigfunc now has a different signature from the system's signal handler type, SIG_IGN and SIG_DFL can no longer be passed directly to pqsignal(). Introduce PG_SIG_IGN and PG_SIG_DFL macros that cast to the new pqsigfunc type, and update all call sites. The legacy pqsignal() in libpq retains its original signature via a local typedef. Only die() reads pg_siginfo today, copying the sender PID/UID into ProcDieSenderPid/Uid for later use by ProcessInterrupts(). Only the first SIGTERM's sender info is recorded. Also fix the syncrep.c translatability issue by using separate ereport calls with complete, independently translatable errdetail strings. Also make the psql TAP test require the DETAIL line on platforms with SA_SIGINFO, rather than making it unconditionally optional. On Windows, pg_signal_info uses uint32_t for pid and uid fields since pid_t/uid_t are not available early enough in the include chain. The Windows signal dispatch in pgwin32_dispatch_queued_signals() passes a zeroed pg_signal_info to handlers. Author: Andres Freund Author: Jakub Wartak Reviewed-by: Andrew Dunstan Reviewed-by: Chao Li Discussion: https://postgr.es/m/cwyyryh2veejuxbj5ifzyaejw7jhhqc5mrdeq56xckknsdecn2@6hzfcxde2nm5 Discussion: https://postgr.es/m/jygesyr7mwg7ovdbxpmjvvbi3hccptpkcreqb645h7f56puwbz@hmkkwi3melfe

libpq: Split PGOAUTHDEBUG=UNSAFE into multiple options

2026-04-07T15:15:14+00:00

PGOAUTHDEBUG is a blunt instrument: you get all the debugging features, or none of them. The most annoying consequence during manual use is the Curl debug trace, which tends to obscure the device flow prompt entirely. The promotion of PGOAUTHCAFILE into its own feature in 993368113 improved the situation somewhat, but there's still the discomfort of knowing you have to opt into many dangerous behaviors just to get the single debug feature you wanted. Explode the PGOAUTHDEBUG syntax into a comma-separated list. The old "UNSAFE" value enables everything, like before. Any individual unsafe features still require the envvar to begin with an "UNSAFE:" prefix, to try to interrupt the flow of someone who is about to do something they should not. So now, rather than PGOAUTHDEBUG=UNSAFE # enable all the unsafe things a developer can say PGOAUTHDEBUG=call-count # only show me the call count. safe! PGOAUTHDEBUG=UNSAFE:trace # print secrets, but don't allow HTTP To avoid adding more build system scaffolding to libpq-oauth, implement this entirely in a small private header. This unfortunately can't be standalone, so it needs a headerscheck exception. Author: Zsolt Parragi Co-authored-by: Jacob Champion Reviewed-by: Chao Li Reviewed-by: Zsolt Parragi Discussion: https://postgr.es/m/CAOYmi%2B%3DfbZNJSkHVci%3DGpR8XPYObK%3DH%2B2ERRha0LDTS%2BifsWnw%40mail.gmail.com Discussion: https://postgr.es/m/CAN4CZFMmDZMH56O9vb_g7vHqAk8ryWFxBMV19C39PFghENg8kA%40mail.gmail.com

libpq: Allow developers to reimplement libpq-oauth

2026-03-31T18:47:26+00:00

For PG19, since we won't have the ability to officially switch out flow plugins, relax the flow-loading code to not require the internal init function. Modules that don't have one will be treated as custom user flows in error messages. This will let bleeding-edge developers more easily test out the API and provide feedback for PG20, by telling the runtime linker to find a different libpq-oauth. It remains undocumented for end users. Reviewed-by: Zsolt Parragi Reviewed-by: Chao Li Discussion: https://postgr.es/m/CAOYmi%2BmrGg%2Bn_X2MOLgeWcj3v_M00gR8uz_D7mM8z%3DdX1JYVbg%40mail.gmail.com