On Wed, Jun 10, 2026 at 12:48 PM Amit Kapila <[email protected]> wrote: > > On Mon, Jun 8, 2026 at 7:01 PM Dilip Kumar <[email protected]> wrote: > > > > On Mon, Jun 8, 2026 at 11:43 AM shveta malik <[email protected]> wrote: > > > > > > On Fri, Jun 5, 2026 at 4:22 PM Dilip Kumar <[email protected]> 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
