Hi,
On 4/7/23 7:56 AM, Andres Freund wrote:
Hi,
On 2023-04-07 07:02:04 +0200, Drouvot, Bertrand wrote:
Done in V63 attached and did change the associated comment a bit.
Can you send your changes incrementally, relative to V62? I'm polishing them
right now, and that'd make it a lot easier to apply your changes ontop.
Sure, please find them enclosed.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
diff --git a/src/test/recovery/t/035_standby_logical_decoding.pl
b/src/test/recovery/t/035_standby_logical_decoding.pl
index a4f9a3c972..5b6d19d379 100644
--- a/src/test/recovery/t/035_standby_logical_decoding.pl
+++ b/src/test/recovery/t/035_standby_logical_decoding.pl
@@ -6,7 +6,7 @@ use warnings;
use PostgreSQL::Test::Cluster;
use PostgreSQL::Test::Utils;
-use Test::More tests => 67;
+use Test::More;
my ($stdin, $stdout, $stderr, $cascading_stdout, $cascading_stderr, $ret,
$handle, $slot);
@@ -112,8 +112,7 @@ sub check_slots_dropped
check_pg_recvlogical_stderr($slot_user_handle, "conflict with
recovery");
}
-# Check if all the slots on standby are dropped. These include the 'activeslot'
-# that was acquired by make_slot_active(), and the non-active 'inactiveslot'.
+# Change hot_standby_feedback and check xmin and catalog_xmin values.
sub change_hot_standby_feedback_and_wait_for_xmins
{
my ($hsf, $invalidated) = @_;
@@ -560,7 +559,7 @@ ok( find_in_log(
'activeslot slot invalidation is logged due to wal_level');
# Verify that pg_stat_database_conflicts.confl_active_logicalslot has been
updated
-# we now expect 3 conflicts reported as the counter persist across reloads
+# we now expect 4 conflicts reported as the counter persist across reloads
ok( $node_standby->poll_query_until(
'postgres',
"select (confl_active_logicalslot = 4) from pg_stat_database_conflicts
where datname = 'testdb'", 't'),
@@ -703,3 +702,5 @@ ok( pump_until(
chomp($cascading_stdout);
is($cascading_stdout, $expected,
'got same expected output from pg_recvlogical decoding session on
cascading standby');
+
+done_testing();
diff --git a/src/backend/access/transam/xlogrecovery.c
b/src/backend/access/transam/xlogrecovery.c
index cc4f7b5302..e6427c54c5 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -1945,7 +1945,7 @@ ApplyWalRecord(XLogReaderState *xlogreader, XLogRecord
*record, TimeLineID *repl
* Indeed, logical walsenders on standby can't decode and send data
until
* it's been applied.
*
- * Physical walsenders don't need to be wakon up during replay unless
+ * Physical walsenders don't need to be woken up during replay unless
* cascading replication is allowed and time line change occured (so
that
* they can notice that they are on a new time line).
*
@@ -1953,9 +1953,11 @@ ApplyWalRecord(XLogReaderState *xlogreader, XLogRecord
*record, TimeLineID *repl
*
* - physical walsenders in case of new time line and cascade
* replication is allowed.
- * - always true for logical walsenders.
+ * - logical walsenders in case cascade replication is allowed (could
not
+ * be created otherwise).
*/
- WalSndWakeup(switchedTLI && AllowCascadeReplication(), true);
+ if (AllowCascadeReplication())
+ WalSndWakeup(switchedTLI, true);
/*
* If rm_redo called XLogRequestWalReceiverReply, then we wake up the
