From 24f608625f9ab5632897d21e0dc27ebfea5d3661 Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Wed, 9 Jul 2025 09:44:27 +0530 Subject: [PATCH 1/2] Doc: Improve logical replication failover documentation. Clarified that the failover steps apply to a specific PostgreSQL subscriber and added guidance for verifying replication slot synchronization during planned failover. Additionally, corrected the standby query to avoid false positives by checking invalidation_reason IS NULL instead of conflicting. Author: Ashutosh Bapat Author: Shveta Malik Backpatch-through: 17, where it was introduced Discussion: https://www.postgresql.org/message-id/CAExHW5uiZ-fF159=jwBwPMbjZeZDtmcTbN+hd4mrURLCg2uzJg@mail.gmail.com --- doc/src/sgml/logical-replication.sgml | 42 +++++++++++++++++++++++---- 1 file changed, 37 insertions(+), 5 deletions(-) diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml index f317ed9c50e59..e26f7f59d4a5a 100644 --- a/doc/src/sgml/logical-replication.sgml +++ b/doc/src/sgml/logical-replication.sgml @@ -709,8 +709,8 @@ HINT: To initiate replication, you must manually create the replication slot, e - To confirm that the standby server is indeed ready for failover, follow these - steps to verify that all necessary logical replication slots have been + To confirm that the standby server is indeed ready for failover for a given subscriber, follow these + steps to verify that all the logical replication slots required by that subscriber have been synchronized to the standby server: @@ -764,7 +764,7 @@ HINT: To initiate replication, you must manually create the replication slot, e Check that the logical replication slots identified above exist on the standby server and are ready for failover. -/* standby # */ SELECT slot_name, (synced AND NOT temporary AND NOT conflicting) AS failover_ready +/* standby # */ SELECT slot_name, (synced AND NOT temporary AND invalidation_reason IS NULL) AS failover_ready FROM pg_replication_slots WHERE slot_name IN ('sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'); @@ -782,10 +782,42 @@ HINT: To initiate replication, you must manually create the replication slot, e If all the slots are present on the standby server and the result (failover_ready) of the above SQL query is true, then - existing subscriptions can continue subscribing to publications now on the - new primary server. + existing subscriptions can continue subscribing to publications on the new + primary server. + + + + The first two steps in the above procedure are meant for a + PostgreSQL subscriber. It is recommended to run + these steps on each subscriber node, that will be served by the designated + standby after failover, to obtain the complete list of replication + slots. This list can then be verified in Step 3 to ensure failover readiness. + Non-PostgreSQL subscribers, on the other hand, may + use their own methods to identify the replication slots used by their + respective subscriptions. + + + + In some cases, such as during a planned failover, it is necessary to confirm + that all subscribers, whether PostgreSQL or + non-PostgreSQL, will be able to continue + replication after failover to a given standby server. In such cases, use the + following SQL, instead of performing the first two steps above, to identify + which replication slots on the primary need to be synced to the standby that + is intended for promotion. This query returns the relevant replication slots + associated with all the failover-enabled subscriptions. + + +/* primary # */ SELECT array_agg(quote_literal(r.slot_name)) AS slots + FROM pg_replication_slots r + WHERE r.failover AND NOT r.temporary; + slots +------- + {'sub1','sub2','sub3', 'pg_16394_sync_16385_7394666715149055164'} +(1 row) + From df286a5b830ae8cc8aac4bd6c999ea4991f0b092 Mon Sep 17 00:00:00 2001 From: Michael Paquier Date: Wed, 9 Jul 2025 15:46:31 +0900 Subject: [PATCH 2/2] libpq: Add TAP test for nested service file This test corresponds to the case of a "service" defined in a service file, that libpq is not able to support in parseServiceFile(). This has come up during the review of a patch to add more features in this area, useful on its own. Piece extracted from a larger patch by the same author. Author: Ryo Kanbayashi Discussion: https://postgr.es/m/Zz2AE7NKKLIZTtEh@paquier.xyz --- src/interfaces/libpq/t/006_service.pl | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/interfaces/libpq/t/006_service.pl b/src/interfaces/libpq/t/006_service.pl index 4fe5adc5c2acd..d896558a6cc24 100644 --- a/src/interfaces/libpq/t/006_service.pl +++ b/src/interfaces/libpq/t/006_service.pl @@ -47,6 +47,12 @@ # Missing service file. my $srvfile_missing = "$td/pg_service_missing.conf"; +# Service file with nested "service" defined. +my $srvfile_nested = "$td/pg_service_nested.conf"; +copy($srvfile_valid, $srvfile_nested) + or die "Could not copy $srvfile_valid to $srvfile_nested: $!"; +append_to_file($srvfile_nested, 'service=invalid_srv' . $newline); + # Set the fallback directory lookup of the service file to the temporary # directory of this test. PGSYSCONFDIR is used if the service file # defined in PGSERVICEFILE cannot be found, or when a service file is @@ -146,6 +152,17 @@ unlink($srvfile_default); } +# Checks nested service file contents. +{ + local $ENV{PGSERVICEFILE} = $srvfile_nested; + + $dummy_node->connect_fails( + 'service=my_srv', + 'connection with nested service file', + expected_stderr => + qr/nested service specifications not supported in service file/); +} + $node->teardown_node; done_testing();