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

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Date: 2025-11-17 06:40:03
Message-ID: CAA4eK1KF88oUa=iO84d25m2YQgHVMoWYDuTvGE5-b0niF0W9hA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Nov 14, 2025 at 3:14 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Fri, Nov 14, 2025 at 1:25 AM shveta malik <shveta(dot)malik(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sutou Kouhei 2025-11-17 06:40:13 Re: Make COPY format extendable: Extract COPY TO format implementations
Previous Message Dilip Kumar 2025-11-17 06:24:11 Re: Proposal: Conflict log history table for Logical Replication