On Sun, Nov 16, 2025 at 10:40 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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.
After thinking of this case, I'm concerned that we would hit the
existing similar assertion failures or assertions that future changes
could introduce because the value returned by XLogLogicalInfoActive()
could be changed even within the same transaction whereas the result
from XLogStandbyInfoActive() doesn't. One possible change would be to
ensure that XLogLogicalInfoActive() returns the same result within the
same transaction. It would be more straightforward and closer to the
current GUC-based behavior. I've drafted a patch for discussion (while
0001 and 0002 patches are the same as v29 patch set). Feedback is very
welcome.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
