Re: Proposal: Conflict log history table for Logical Replication

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.

--
With Regards,
Amit Kapila.