Re: Proposal: Conflict log history table for Logical Replication

On Thu, Jun 11, 2026 at 9:42 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Wed, Jun 10, 2026 at 3:07 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Wed, Jun 10, 2026 at 12:48 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Mon, Jun 8, 2026 at 7:01 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > >
> > > > On Mon, Jun 8, 2026 at 11:43 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> > > > >
> > > > > On Fri, Jun 5, 2026 at 4:22 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > >
> > > > After rethinking my previous stance on blocking these operations, let
> > > > me clarify the core principle I think we should follow for CLTs. I am
> > > > completely open to feedback on this approach:
> > > >
> > > > 1. Block Direct Mutations: We should block any operation that directly
> > > > modifies the CLT or its underlying data (e.g., DROP TABLE, ALTER
> > > > TABLE, INSERT, UPDATE), which impact the operation on CLT or update
> > > > the CLT data.
> > > > 2. Don't block Indirect/Edge-Case Operations: We should not write
> > > > custom code just to block edge cases that don't directly modify CLT
> > > > data or impact the operations on CLT.
> > >
> > > Unlike system catalogs which are allowed to be modified with the
> > > allow_system_table_mods GUC, the TOAST model seems more appropriate
> > > for conflict log tables where the external modifications are blocked,
> > > due to following reasons:
> > > 1. The apply worker assumes a fixed schema. ConflictLogSchema[] in
> > > conflict.c is a hardcoded array of column definitions used to build
> > > tuples at runtime. If allow_system_table_mods=on lets someone add a
> > > column or attach a trigger that errors out, the apply worker's
> > > insertion path breaks with error or crash. There is no recovery path —
> > > it's not like a user catalog where a DBA might legitimately need to
> > > patch something in an emergency.
> > > 2. allow_system_table_mods allowed to modify catalog tables and that
> > > seems to be designed for bootstrap, not conflict log tables. The GUC
> > > exists so initdb can modify system catalogs they own. Conflict log
> > > tables are subscription-specific runtime objects. No legitimate
> > > internal tooling scenario requires adding triggers or rules to them.
> > >
> > > There could be other cases for allow_system_table_mods to allow
> > > modifying system catalog for emergency repair of catalog table or some
> > > upgrade scripts used by extensions to allow adding additional entries
> > > in catalog tables like pg_proc but I don't see such maintenance
> > > required for conflict log tables. So, it seems better to block all the
> > > additional operations discussed.
> > >
> >
> > +1. irrespective of GUC value, we can block such operations. Some
> > operations are allowed even with this GUC set to false (as stated in
> > my previous emails).
>
> Yeah that makes sense. Here is the POC patch to block such operations
> for the conflict log table. Please let me know your thoughts

Please find the rebased patch
1. It includes the new 0005 patch for reporting errors for DDLs on clt.

Open comments:
1. Recent comments from Nisha and Shveta after v47 are still open
2. Vignesh's patch for "describe related" changes needs a rebase. Can
you do that, Vignesh? Meanwhile, I will close all the open comments
and try to share a new version by EOD today.

--
Regards,
Dilip Kumar
Google