Horton

Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Peter Smith <smithpb2250@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-11-28T05:00:28Z
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 →

  1. Fix regression test failure when wal_level is set to minimal.

  2. Toggle logical decoding dynamically based on logical slot presence.

  3. Disallow server start with sync_replication_slots = on and wal_level < logical.

On Thu, Nov 27, 2025 at 4:33 PM shveta malik <shveta.malik@gmail.com> 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