On Fri, Nov 14, 2025 at 3:14 PM Masahiko Sawada <[email protected]> wrote: > > On Fri, Nov 14, 2025 at 1:25 AM shveta malik <[email protected]> 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.
