Horton

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

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: shveta malik <shveta.malik@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>
Date: 2025-12-04T02:33:20Z
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 Mon, Dec 1, 2025 at 12:54 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> On Mon, Dec 1, 2025 at 11:40 AM Masahiko Sawada <sawada.mshk@gmail.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.

Hmm, I'm not sure there is a big difference there. If we show the
message first that indicates that the slot is invalidated, users would
drop the slot and try to create a new logical slot, but they would get
the error 'logical decoding on standbys requires "effective_wal_level"
>= "logical" on the primary'. With the current implementation, they
would enable logical decoding on the primary first, realize that the
slot on the standby is already invalidated, and then create a new
logical slot.

Regards,

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