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

On Tue, Aug 26, 2025 at 2:32 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Tue, Aug 26, 2025 at 12:54 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > I've attached the updated patch that incorporated the comments and is
> > rebased to the current HEAD.
> >
>
> Thanks for the patch, please find a few comments concerning LOG messages:

Thank you for reviewing the patch!

>
> 1)
> slotsync worker gives LOG:
> LOG: replication slot synchronization requires logical decoding to be enabled
>
> By this LOG message, the user might not know how to enable logical
> decoding. Shall we add HINT/DETAIL similar to other places:
> To enable logical decoding on standby, set "wal_level" >= "logical" or
> create at least one logical slot on the primary server.

Sounds good.

>
> 2)
> When we try to create a logical slot on standby, it takes some time
> until runnign-txns are logged on primary. During that wait-time, if we
> drop logical slot on primary disabling logical_deocding on standby,
> then slot-creation fails with:
>
> postgres=# SELECT pg_create_logical_replication_slot('st_slot2',
> 'pgoutput', false, false, false);
> ERROR: canceling statement due to conflict with recovery
> DETAIL: User was using a logical replication slot that must be invalidated.
>
> Do we need to tweak the message a little bit as this new case is is
> not the case of invalidation?

I think this is the case of invalidation but why do you think it's not?

>
> 3)
> When slot is invalidated on standby, we get message:
>
> LOG: invalidating obsolete replication slot "st_slot"
> DETAIL: Logical decoding on standby requires "wal_level" >= "logical"
> or to create at least one logical slot on the primary server.
>
> The DETAIL msg looks slightly odd. Shall we make it as:
> Logical decoding on standby requires "wal_level" >= "logical" or at
> least one logical slot on the primary server.

Agreed.

When testing the patch further, I found a bug in a race condition in
case of aborting the activation process. In the attached latest
version patch, I've fixed the bug and included the test case to the
new TAP test.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com