Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>,
Sawada Masahiko <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>,
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
shveta malik <shveta.malik@gmail.com>
Date: 2025-10-27T05:36:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix regression test failure when wal_level is set to minimal.
- 0de5f0d869d1 19 (unreleased) landed
-
Toggle logical decoding dynamically based on logical slot presence.
- 67c20979ce72 19 (unreleased) landed
-
Disallow server start with sync_replication_slots = on and wal_level < logical.
- 12da45742cfd 19 (unreleased) cited
On Mon, Oct 27, 2025 at 7:44 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> Hi Sawada-San,
>
> Some review comments for v22-0002:
>
> ======
> doc/src/sgml/logicaldecoding.sgml
>
> 1.
> consistency. Conversely, when the last logical replication slot is dropped
> - from a system with <varname>wal_level</varname> set to
> <literal>replica</literal>,
> - logical decoding is automatically disabled. Note that the deactivation of
> - logical decoding might take some time as it is performed asynchronously
> - by the checkpointer process.
> + from a system or invalidated with <varname>wal_level</varname> set to
> + <literal>replica</literal>, logical decoding is automatically disabled.
> + Note that the deactivation of logical decoding might take some time as it
> + is performed asynchronously by the checkpointer process.
> </para>
>
> I felt that "Conversely..." sentence should be worded more like the
> 1st sentence of the paragraph.
>
> CURRENT
> Conversely, when the last logical replication slot is dropped from a
> system or invalidated with <varname>wal_level</varname> set to
> <literal>replica</literal>, logical decoding is automatically
> disabled.
>
> SUGGESTION
> Conversely, if <varname>wal_level</varname> is
> <literal>replica</literal> and the last logical replication slot is
> dropped or invalidated, logical decoding is automatically disabled.
>
> (Aside: most of this suggestion maybe belongs for patch 0001 -- only
> the "or invalidated" part is added for patch 0002)
>
> ======
> src/backend/replication/slot.c
>
> ReplicationSlotsDropDBSlots:
>
> 2.
> - nlogicalslots++;
> + if (s->data.invalidated == RS_INVAL_NONE)
> + n_valid_logicalslots++;
>
> /* not our database, skip */
> if (s->data.database != dboid)
> continue;
>
> Should that counter increment be moved to be *below* the "not our
> database, skip" code?
>
Logical-decoding enabling/disabling is not db-specific. If we move the
counter-increment below db-oid check, we may end up wrongly requesting
disabling of logical decoding when we drop a particular DB while
another DB still has slots.
> ~~~
>
> CheckLogicalSlotExists:
>
> 3.
> /*
> - * Returns true if there is at least in-use logical replication slot.
> + * Returns true if there is at least in-use valid logical replication slot.
> */
> bool
> CheckLogicalSlotExists(void)
>
> Typo? /is at least in-use valid/is at least one in-use valid/
>
> ~~~
>
> 4.
> + if (SlotIsLogical(s))
> + {
> + if (s->data.invalidated == RS_INVAL_NONE)
> + n_valid_logicalslots++;
> +
> + /* Prevent invalidation of logical slots during binary upgrade */
> + if (IsBinaryUpgrade)
> + continue;
> + }
>
> Is it better to do the binary check first, before the n_valid_logicalslots++?
I agree with this one.
>
> ======
> src/test/recovery/t/049_effective_wal_level.pl
>
> 5.
> -# Promote the standby4 and check if effective_wal_level remains 'logical' even
> -# after the promotion since it has an invalidated logical slot.
> +# Promote the standby4 and check if effective_wal_level is now 'logical' after
> +# the promotion since there is no valid logical slot.
> $standby4->promote;
> -test_wal_level($standby4, "replica|logical",
> - "effective_wal_level remains 'logical' even after promotion as it
> has one invalidated slot"
> +test_wal_level($standby4, "replica|replica",
> + "effective_wal_level got decreased to 'replica' as there is no valid
> logical slot"
> );
>
> The test comment seems wrong; shouldn't it say "check if
> effective_wal_level_got decreased to replica"?
>
> ~~~
>
> 6.
> # Drop the invalidated slot, decreasing effective_wal_level to 'replica'.
> @@ -287,7 +326,7 @@ $standby4->safe_psql('postgres',
> qq[select pg_drop_replication_slot('standby4_slot')]);
> wait_for_logical_decoding_disabled($standby4);
> test_wal_level($standby4, "replica|replica",
> - "effective_wal_level got decreased to 'replica' after dropping the
> last invalidated slot"
> + "effective_wal_level doesn't change after dropping the last invalidated slot"
> );
>
> The test comment seems wrong; effective_wal_level was already
> 'replica' before this test.
>
Apart from the comments by Peter above, I have no more comments on
002. Verified, it works well.
thanks
Shveta