postgresql.git/src/backend/tcop, branch REL_19_STABLE

Revert SQL Property Graph Queries (SQL/PGQ)

2026-09-07T19:03:10Z

List of commits reverted: 2f094e7ac69 SQL Property Graph Queries (SQL/PGQ) cd8844e7db6 Make some tests more stable by adding more explicit ordering 182cdf5aeaf pg_dump: Add appropriate version check c9babbc8816 Dump labels in reproducible order 040a56be4bc Cleanup users and roles in graph_table_rls test 5282bf535e4 Fix some typos and make small stylistic improvements 720f0f89d69 Reject consecutive element patterns of same kind 288ae968726 Add a graph pattern variable only once c5b3253b8ab Property references are preferred over regular column references a0dd0702e46 Fix cross variable references in graph pattern causing segfault 2ff289d0393 Check for stack overflow when rewriting graph queries 9082680c34e Fix typos and grammar in graph table rewrite code ac3bcc041c5 Fix collation of expressions in GRAPH_TABLE COLUMNS clause 9d2979dd685 pg_get_viewdef() and lateral references in COLUMNS of GRAPH_TABLE 891a57c7394 Do not define type for a property graph dc9e7c9ed93 Handle nodes that may appear in GraphPattern expression trees f6edd8ed708 Add ORDER BY to test query to stabilize test 1190f858eaf doc: Small synopsis wording change for consistency d0eac3cafb0 Make spelling consistent 6827de95ee0 Simplify code in objectaddress.c for some property graph objects 5778fb3eafd Fix typo in error message 72498a86989 Handle element label and label property objects in object address functions 4cb2a9863d8 Fix LATERAL references in GRAPH_TABLE with multi-label pattern 9d8cdcbe0c8 Record dependencies on graph labels and properties 2a7e95b659d Readable identity strings for property graph objects ac0ad6a7c9d Prevent dropping the last label from a property graph element 36aae3d0297 Fix handling of dropping a property not associated with the given label cc9aa7f3a98 Resolve unknown-type literals in GRAPH_TABLE COLUMNS d8687368300 Make property graph object descriptions better translatable 45d4c917ff4 Fix properties orphaned by dropping a label 33bfad0f3ca Remove apparent support for SECURITY LABEL ON PROPERTY GRAPH ccca2cd81b2 Fix pg_dump ACL minimization for PROPERTY GRAPH. 7883ea13ffd Fix replace_property_refs() ignoring the root of expression tree b820c623dd5 Resolve unknown-type literals in property expressions 01c544e1afb Prohibit locking clauses on GRAPH_TABLE 8d2beee027a Restore the ability to use | and -> as prefix operators. d2ac26eb9b1 Fix missing space before WHERE in GRAPH_TABLE deparse 4054ec5b4f3 Prohibit GRANT ... ON TABLE on a property graph 77964322d60 doc: Add PROPERTY GRAPH to the access privilege tables c5e11de2f37 More tab-completion for DROP PROPERTY GRAPH 8ce749f8f65 Disallow aggregates, window functions, and SRFs in GRAPH_TABLE COLUMNS 22d0eebfef7 Report duplicate property and label names with a proper error 41a300ae3df Make generate_queries_for_path_pattern_recurse() interruptible 58af2138740 Fix inferred property graph keys with INCLUDE columns 63f8e9773aa Fix pg_event_trigger_ddl_commands for GRANT ON PROPERTY GRAPH 07df2b25327 doc: reformat GRAPH_TABLE examples 1c8c790ec10 Coerce GRAPH_TABLE pattern WHERE clauses to boolean plus release notes entries and typedefs.list changes. Discussion: https://www.postgresql.org/message-id/CAAKRu_bEtjWYWhYxSo0o_t3DaZYRQd5PkC0abA0g9Mp4%2BovH0w%40mail.gmail.com

Check for USAGE privilege on types used by stored expressions.

2026-08-10T13:38:06Z

This omission allowed roles without USAGE on a type to create stored expressions that depend on it, which could prevent the owner from changing the type later. The checks deliberately live in the command paths rather than the dependency-recording routines. Those routines also run whenever the server re-derives an existing expression, and re-checking there would break routine maintenance for an owner who has since lost USAGE on a type its objects already reference. (Checking in the dependency-recording routines would also require additional CommandCounterIncrement() calls to avoid spurious errors.) The addition of a parameter to AlterDomainAddConstraint() breaks ABI compatibility, but we are unaware of any impacted third-party code. Reported-by: Noah Misch Author: Nathan Bossart Reviewed-by: Noah Misch Reviewed-by: Tom Lane Reviewed-by: Robert Haas Security: CVE-2026-6470 Backpatch-through: 14

Cross-check the type of a portal running EXECUTE or FETCH.

2026-08-10T13:38:05Z

When an EXECUTE or FETCH statement is executed, there are two portals: an outer portal that is created for the EXECUTE or FETCH statement itself, and an inner portal for the statement being executed on its behalf. Before this commit, nothing checked that these two portals agreed on the tuple descriptor of the rows being returned. This can be leveraged to disclose server memory contents and achieve arbitrary code execution. To prevent that, we can make use of an existing safety mechanism, added by Tom Lane in commit 2f48ede080f42b97b594fb14102c82ca1001b80c, which allows a tuplestore DestReceiver to be informed of the tupleDesc required by the caller, and which will cause an ERROR to occur if that doesn't match the tupleDesc of what emerges from the executor (modulo dropped columns, which aren't an issue in the case at hand). Reported-by: Ben Morris in collaboration with Claude and Anthropic Research Reported-by: Peter Geoghegan Reviewed-by: Michael Paquier Security: CVE-2026-16239

Reject GSSEncRequest after direct SSL connection

2026-08-10T13:38:05Z

When a direct SSL connection was established, ProcessStartupPacket() still accepted GSSEncRequest messages. The GSSAPI negotiation would then use raw writes and reads, bypassing the TLS encryption layer. After the GSS encryption was established, the connection continued to use TLS. This could betray the HBA rules so as the backend does protocol exchanges inconsistent with the connection policies in place, with TLS taking priority over GSS in the backend. The SSL negotiation path already guarded against attempts to request SSL after a direct SSL request has been processed. The GSS path is now guarded the same way when receiving a startup packet. Reported-by: p4p3r Author: Michael Paquier Reviewed-by: Jacob Champion Backpatch-through: 17 Security: CVE-2026-14681

Preserve the owner of extended statistics rebuilt by ALTER TABLE.

2026-08-10T13:38:04Z

When ALTER TABLE ... ALTER COLUMN TYPE (or any subcommand that rebuilds them) drops and re-creates the extended statistics objects depending on the altered column, the re-created objects were owned by the role running ALTER TABLE rather than by the original owner of the statistics. Remember each object's owner before dropping it, and restore it on re-creation. CreateStatistics()'s signature changes and CreateStatsStmt gains a field, but no known third-party code calls the former or constructs the latter. Author: Masahiko Sawada Reviewed-by: Noah Misch Backpatch-through: 14 Security: CVE-2026-6469

Simplify signature of ProcessStartupPacket()

2026-05-16T22:44:17Z

There is now only one caller of ProcessStartupPacket(). Let's simplify the routine so as the GSS and SSL states are tracked inside it. If future callers are added, there is less guessing to do. Suggested-by: Daniel Gustafsson Reviewed-by: Daniel Gustafsson Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/aga7lCWluyc5zLb5@paquier.xyz

Fix unbounded recursive handling of SSL/GSS in ProcessStartupPacket()

2026-05-11T12:13:46Z

The handling of SSL and GSS negotiation messages in ProcessStartupPacket() could cause a recursion of the backend, ultimately crashing the server as the negotiation attempts were not tracked across multiple calls processing startup packets. A malicious client could therefore alternate rejected SSL and GSS requests indefinitely, each adding a stack frame, until the backend crashed with a stack overflow, taking down a server. This commit addresses this issue by modifying ProcessStartupPacket() so as processed negotiation attempts are tracked, preventing infinite recursive attempts. A TAP test is added to check this problem, where multiple SSL and GSS negotiated attempts are stacked. Reported-by: Calif.io in collaboration with Claude and Anthropic Research Author: Michael Paquier Reviewed-by: Daniel Gustafsson Security: CVE-2026-6479 Backpatch-through: 14

Only show signal-sender PID/UID detail in server log

2026-05-01T17:20:08Z

The errdetail() added in 55890a91945 (and reworked in 3e2a1496bae) exposed the operating-system PID and UID of whoever sent the termination signal directly to the affected client. Discussion suggested this should not be sent to the client, but only recorded in the server log where the admin can use it for diagnosis. Author: Chao Li Reviewed-by: Jakub Wartak Discussion: https://postgr.es/m/E5CA274C-74BD-4067-8B73-A3AD8C080EFA@gmail.com

Avoid blocking indefinitely while finishing walsender shutdown

2026-05-01T03:12:44Z

When walsender finishes streaming during shutdown, it sends a CommandComplete message to tell the receiver that WAL streaming is done. Previously, that path used EndCommand() followed by pq_flush(). Those functions can block indefinitely waiting for the socket to become writeable. As a result, even when wal_sender_shutdown_timeout is set, walsender could remain stuck while sending the final completion message, and the shutdown timeout would not be enforced. Fix this by introducing EndCommandExtended(), which allows CommandComplete to be queued with pq_putmessage_noblock(), and by using the walsender nonblocking flush path instead of pq_flush(), so the shutdown timeout continues to be checked while pending output is flushed. Per CI testing on FreeBSD. Reported-by: Andres Freund Author: Fujii Masao Reviewed-by: Chao Li Discussion: https://postgr.es/m/vwlugmsogfn36jhm56zwrgd7m6xe6ircltvfh3kzt6kldvbtht@f45dgow5uhnx

Rework signal handler infrastructure to pass sender info as argument.

2026-04-15T11:30:34Z

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