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.
