On Thu, Nov 27, 2025 at 4:33 PM shveta malik <[email protected]> wrote: > > A few more comments: > > > 10) > +# Promote standby3, increasing effective_wal_level to 'logical' as > its wal_level > +# is set to 'logical'. > +$standby3->promote; > + > +# Check if effective_wal_level is increased to 'logical' on the > cascaded standby. > +$standby3->wait_for_replay_catchup($cascade); > +test_wal_level($cascade, "replica|logical", > + "effective_wal_level got increased to 'logical' on standby as the > new primary has wal_level='logical'" > +); > > The message is slightly confusing due to usage of both 'standby' and > 'new primary'. Can we make it: > effective_wal_level got increased to 'logical' as the new primary has > wal_level='logical' >
Upon reconsideration, we can keep it as is. I understand the intent now. === I tried to test possible race-scenarios (known to me), they seem to work well, except one minor thing: Let's say there is slot1 present, backend1 is trying to drop slot1 and backend2 is trying to create slot2. DisableLogicalDecodingIfNecessary() first kicks in and reaches the stage where it has disabled and released the lock. Before it could EmitSignal and log, EnsureLogicalDecodingEnabled() kicks in and completes its execution. In such a case we end up with reverse LOG messages in log file: 09:47:16.489 IST LOG: logical decoding is enabled upon creating a new logical replication slot 09:47:17.484 IST LOG: logical decoding is disabled because there are no valid logical replication slots while logical decoding is actually enabled in the system. Shall we check 'if (!LogicalDecodingCtl->xlog_logical_info)' before logging in DisableLogicalDecodingIfNecessary()? thanks Shveta
