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

On Mon, Dec 1, 2025 at 11:40 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
>
> > 11)
> > my ($result, $stdout, $stderr) = $standby4->psql('postgres',
> > qq[select pg_logical_slot_get_changes('standby4_slot', null, null)]);
> > like(
> > $stderr,
> > qr/ERROR: logical decoding on standby requires "effective_wal_level"
> > >= "logical" on the primary/,
> > "cannot use logical decoding on standby as it is disabled on primary");
> >
> > Since the slot is invalidated, shouldn't the better error message be
> > what we usually get:
> > ERROR: can no longer access replication slot "slot"
> > DETAIL: This replication slot has been invalidated due to "..".
> >
> > IMO, the 'invalidated' message is better because even if we enable
> > logical-decoding on primary, it is of no use for this slot.
> >
> > But I also see the difficulty in achieving this, as the
> > primary-related error message is by CheckLogicalDecodingRequirements()
> > which happens earlier than
> > ReplicationSlotAcquire(). So if there is no better way, we can leave it as is.
>
> We can achieve it by creating another valid logical slot, but I
> believe that we already have tests to check if we cannot use an
> invalidated slot. What we want to test here is if logical decoding is
> disabled by invalidating the last logical slot. So I think the test
> works as expected.
>

Sorry for the confusion. My earlier comment wasn’t about the test
mechanics or correctness. I meant that when a slot is invalidated and
someone attempts to use it, the message should reflect that (can no
longer access replication slot "slot"). Currently, the message
suggests enabling logical decoding on the primary, even though that
won’t make an invalidated slot usable. IMO, it would be clearer to
report that the slot is invalidated instead of directing the user to
enable decoding on primary.

thanks
Shveta