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

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>, shveta malik <shveta.malik@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-09-16T08:29:55Z
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, Sep 15, 2025 at 10:15 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Sun, Sep 14, 2025 at 7:55 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Fri, Sep 12, 2025 at 11:18 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > >
> > > On Thu, Sep 11, 2025 at 9:08 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > >
> > >
> > > > For the shutdown sequence, can't we think of resetting effective_wal
> > > > after a restart?
> > >
> > > Does it mean that effective_wal_level keeps 'logical' until the next
> > > server starts?
> > >
> >
> > Yes, IIUC, effective_wal_level is anyway a derived value based on
> > current wal_level and presence of logical slots. So, what will be the
> > impact if it is not accurate at shutdown?
>
> I think there won't be an impact at shutdown time. I would rather be
> concerned that such behavior could confuse users. I think it would not
> be a rare situation where users enable and disable logical decoding by
> creating and dropping a temporary slot. If we keep effective_wal_level
> 'logical' in this case, users would want to somehow disable logical
> decoding as it could have a negative performance impact.
>

When user is dropping a temporary slot, we should disable the
decoding. The lazy behaviour should be for ERROR or session_exit
cases.

> There would
> be two ways for users to change it to 'replica': restart the server or
> create and drop a logical slot again.
>

If we do the lazy work during the checkpoint then they can perform the
checkpoint command.

 On the other hand, for users who
> dropped a non-temporary logical slot without an error or dropped the
> non-last temporary slot, logical decoding is disabled without other
> manual interventions. It could be pretty hard to assess the situation,
> resulting in having users always checking effective_wal_level after
> dropping a logical slot and doing extra steps to make the
> effective_wal_level 'replica'.
>

When the last slot is dropped, anyway, users won't be able to perform
any decoding. Do you mean that they want to know whether logical_wal
is still being recorded? If so, then checking effective_wal_level
would be the way.

-- 
With Regards,
Amit Kapila.