pgsql: pg_createsubscriber: Only --recovery-timeout controls the end of

pg_createsubscriber: Only --recovery-timeout controls the end of recovery process It used to check if the target server is connected to the primary server (send required WAL) to rapidly react when the process won't succeed. This code is not enough to guarantee that the recovery process will comp

pgsql: pg_createsubscriber: Remove replication slot check on primary

pg_createsubscriber: Remove replication slot check on primary It used to check if the replication slot exists and is active on primary. This check might fail on slow hosts because the replication slot might not be active at the time of this check. The current code obtains the replication slot na

pgsql: pg_createsubscriber: Remove failover replication slots on subscr

pg_createsubscriber: Remove failover replication slots on subscriber After running pg_createsubscriber, these replication slots have no use on subscriber, so drop them. Author: Euler Taveira Reviewed-by: Hayato Kuroda Discussion: https://www.postgresql.org/message-id/776c5cac-5ef5-4001-b1bc-5b

pgsql: Teach jsonpath string() to unwrap in lax mode

Teach jsonpath string() to unwrap in lax mode This was an ommission in commit 66ea94e, and brings it into compliance with both other methods and the standard. Per complaint from David Wheeler. Author: David Wheeler, Jeevan Chalke Reviewed-by: Chapman Flack Discussion: https://postgr.es/m/a64ae

pgsql: Remove recordExtensionInitPriv[Worker]'s ownerId argument.

Remove recordExtensionInitPriv[Worker]'s ownerId argument. In the wake of the previous commit, we're not doing anything with that argument. Hence, revert the portions of 534287403 that added that argument and taught the callers to pass it. Passing the ownerId requires additional syscache lookups

pgsql: Improve tracking of role dependencies of pg_init_privs entries.

Improve tracking of role dependencies of pg_init_privs entries. Commit 534287403 invented SHARED_DEPENDENCY_INITACL entries in pg_shdepend, but installed them only for non-owner roles mentioned in a pg_init_privs entry. This turns out to be the wrong thing, because there is nothing to cue REASSIG

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRE

Fix insertion of SP-GiST REDIRECT tuples during REINDEX CONCURRENTLY. Reconstruction of an SP-GiST index by REINDEX CONCURRENTLY may insert some REDIRECT tuples. This will typically happen in a transaction that lacks an XID, which leads either to assertion failure in spgFormDeadTuple or to insert

pgsql: doc PG 17 relnotes: Fix sslnegotation typo

doc PG 17 relnotes: Fix sslnegotation typo I was confused with copy-pasting the parameter name didn't work... Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/a6685c5e362eab5d04b8ffe65fff7cfbd21b6034 Modified Files -- doc/src/sgml/release-17.sgml | 2 +-

pgsql: doc PG 17 relnotes: update to current

doc PG 17 relnotes: update to current Backpatch-through: master Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/82ed67a5fe826044bf361ad0425283d05f3dcf95 Modified Files -- doc/src/sgml/release-17.sgml | 14 +++--- 1 file changed, 7 insertions(+),

pgsql: Fix typo in 029_stats_restart.pl

Fix typo in 029_stats_restart.pl Oversight in 16acf7f1aaea, where the test has been introduced. Issue noticed while scanning this area of the tree. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ae482a7ec521e09bb0dbfc261da6e6170a5ac29f Modified Files