Horton

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

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: shveta malik <shveta.malik@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-11-17T06:40:03Z
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 Fri, Nov 14, 2025 at 3:14 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Fri, Nov 14, 2025 at 1:25 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > In an offline discussion with Kuroda-san, we realized that TRUNCATE
> > may hit Assert(XLogLogicalInfoActive()) in ExecuteTruncateGuts() under
> > our current implementation, where logical decoding is disabled lazily.
> >
> > Consider the case where there’s only one logical slot and we attempt
> > to drop it. The backend issues the drop request, but before the
> > checkpointer actually disables logical decoding, a TRUNCATE is
> > executed. Since logical decoding is still marked as active at that
> > moment, the ExecuteTruncate() appends the OID to relids_logged.
> > However, by the time control reaches ExecuteTruncateGuts, the
> > checkpointer has already disabled logical decoding resulting in
> > Assert.
> >
> > TRAP: failed Assert("XLogLogicalInfoActive()"), File: "tablecmds.c",
>
> Good find. I think this assertion is no longer valid given that
> XLogLogicalInfoActive() can change dynamically. It's safe to write
> logica information to WAL records even if it's not strictly required,
> so we can keep writing logical info even if XLogLogicalInfoActive()
> comes to return false in the middle. In the opposite case where
> logical decoding becomes enabled in the middle, a similar thing
> happens but we will wait for such a transaction to finish before
> starting the logical decoding. Therefore, we can remove the assertion.
> What do you think?
>

I also think it is safe to remove this assertion.

> I'll check if there are other similar issues due to this patch.
>

Yes, that makes sense. In the worst case, if we find some hard to
remove dependencies either now or in future then we can let DISABLE of
logical_decoding operation wait for current transactions to finish
like we are doing for corresponding ENABLE operation.

-- 
With Regards,
Amit Kapila.