Re: Proposal: Conflict log history table for Logical Replication

On Wed, Jun 10, 2026 at 12:48 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jun 8, 2026 at 7:01 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Mon, Jun 8, 2026 at 11:43 AM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > On Fri, Jun 5, 2026 at 4:22 PM Dilip Kumar <dilipbalaut@gmail.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).

thanks
Shveta