mirror of
https://github.com/postgres/postgres.git
synced 2026-10-23 13:29:09 +03:00
ee8f123da7
The regression test for postgres_fdw_get_connections(true) assumed that a terminated remote connection would still remain visible in the FDW connection cache long enough to be reported as closed with a nonzero remote_backend_pid. That assumption is not always valid. postgres_fdw_get_connections() reports only entries that are still present in ConnectionHash, while pgfdw_inval_callback() may immediately discard an idle cached connection (xact_depth == 0) when a relevant invalidation arrives. In CI, that can happen between terminating the remote backend and querying postgres_fdw_get_connections(true), causing the function to return no rows. Adjust the idle-connection test to accept either outcome: if the cache entry is still present, verify that it reports the expected server name, closed status, and nonzero remote backend PID; otherwise treat zero rows as a legitimate result. To preserve coverage of the terminated-backend reporting path, add a separate check inside an explicit transaction. In that case, concurrent invalidation may mark the connection invalid but cannot discard it before transaction end, so postgres_fdw_get_connections(true) should still report the terminated connection as in-use, closed, and associated with a nonzero remote backend PID. Backpatch to v18, where the affected postgres_fdw_get_connections(true) test was introduced. Reported-by: Robert Haas <robertmhaas@gmail.com> Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CA+Tgmoax3cHXHsm9OidN4F-xiu16y8q2W8T5dTNFic1Zoo2cOw@mail.gmail.com Backpatch-through: 18
The PostgreSQL contrib tree
---------------------------
This subtree contains porting tools, analysis utilities, and plug-in
features that are not part of the core PostgreSQL system, mainly
because they address a limited audience or are too experimental to be
part of the main source tree. This does not preclude their
usefulness.
User documentation for each module appears in the main SGML
documentation.
When building from the source distribution, these modules are not
built automatically, unless you build the "world" target. You can
also build and install them all by running "make all" and "make
install" in this directory; or to build and install just one selected
module, do the same in that module's subdirectory.
Some directories supply new user-defined functions, operators, or
types. To make use of one of these modules, after you have installed
the code you need to register the new SQL objects in the database
system by executing a CREATE EXTENSION command. In a fresh database,
you can simply do
CREATE EXTENSION module_name;
See the PostgreSQL documentation for more information about this
procedure.