| 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.
| 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 |