Re: Proposal: Conflict log history table for Logical Replication

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

--
Regards,
Dilip Kumar
Google