Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wXDD3-0037s5-1W for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 07:18:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wXDD2-009mf3-1M for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 07:18:44 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wXDD2-009mes-03 for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 07:18:44 +0000 Received: from mail-pl1-x62d.google.com ([2607:f8b0:4864:20::62d]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wXDD0-00000001yHI-0k2H for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 07:18:43 +0000 Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-2bf2247e38eso66710235ad.3 for ; Wed, 10 Jun 2026 00:18:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781075921; cv=none; d=google.com; s=arc-20240605; b=KzsF4+8ClAt0CtFirL0Xq38umkIjfp3tWfgb1UTXgMee/SGkCVAVcmKnElNK9wUQuG VGCmpGiKP7MqKeqOjky/b3eweaqi8toOhjNKvKlNubNV+NFiFLN2fJu1uxyr8BrwUofH MTIzvKtUY3iVI+p1ZaTrSsIYI0ZGFW/2OlzN/DXVfLl5kWombDvGD5XlCeMLfdrhwxpJ cBD/SpR0Ubmkrh5vmBrqyUGaJ/M0r2b9U6kwbBbfuhmVlpEvnpwzhXlDM3MAOn8G/HbY 9kyOEgKP7KxSCAmhV6oBurtAE2JuVQ9COachZaWDAN3P21UBCAQH6w/NzudQeJRhWyMN M45g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RuwAVVXT2wtxohUHR9c2MZsSdqX1iYlN6gZFiUUFXOs=; fh=HL0LO+aPjONMzWekR0M4XVEya7C+7E4YDxghL/422RA=; b=QXjelmuwx8sgcxAcl0nsmwmASxWIoVBel7lsN+lh4I6CAwl+YPXQ3ND4CQgzBG87OH hhJnusM3qdBCqwtUvkuyLLTlPmD7cgd5mZeBkfjZ74laybxbBTJNpyLLS1McDR58eh1P KrLPlWi2v8r2ArKxKCitzYpB3O7FMmsGugreHQozLTleMhn17NTSfri39w0jz+erksBU oAuvBcAmS0k1eFTqPhZJ4CpAXVCJE72UuVazrDH/+zTGss/vEPGZXqjEpShWdqmJcc2B U+RhwxkOffb20YGOyMvTR0ATFcIaYKzMNan6GPjhjlDkgEe6vMdz+l06jUsybSGX08y9 aXfw==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781075921; x=1781680721; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RuwAVVXT2wtxohUHR9c2MZsSdqX1iYlN6gZFiUUFXOs=; b=HpvhMGDfPvje8rmMsR2pKcythNOX9PGDDK3Z2AHFBO/gk8Ou3sc8BSTrOHfLADt9vR A519s8hne16J960L4WQvRK2YcG7/vQSb/0epx/oWaOj8qblgi1Bq0MJrKZAbmRwDE0i8 CbM8sods3MnPyDPV+a0WGHCPv6sGD3JRVMU/Pq2FCJgrhv6ii3hRXIzoW8jheWPP6UCw joW+sFyLdCFKTheguPO/koe+Lvwjqh//Ho9ByV657AOzCZAt8V2/VxoHrYnD6oap8N95 s6nJM6KVumWpoyUTje5kZuGebRUJQ/i1A7w+hSIITlUXrqnH9ynmVh0N9PfN8sQPkdsf uODQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781075921; x=1781680721; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=RuwAVVXT2wtxohUHR9c2MZsSdqX1iYlN6gZFiUUFXOs=; b=PzDMc1uI4ZVPF4PSCzJOxe0HSeIgj6U12cPzusnKbKe8wi0axFg9ou2a+3yBKn2B+W C9+yzkejh1AfDv45IpNcOh0IgcacXQexj818xl3ko3Nm36DLCCNQnNpgoXR+V4vIawtm XSDCxhfTwJgtDdQnQFX3e6zcTmBn+l51Hlh2rMctuMeUOlnDsKpTwCpE31S+a5njDqL1 UI1JBqAUoTzSILRFV++E+HksJ9E5J5v9JFVtjYAJ/xnSxJvThlH0l0h4Ud5avaNJmnAn q/6CXvy8gVah4wAi68MdKaEllG8Lht3oAPij+I9cDbqfrsK9uDAtdNG9SMJZj11lBHJk EUrQ== X-Forwarded-Encrypted: i=1; AFNElJ96swxtyRYi5JOKqA1hUhdMPIXXqplFYxS2Od7JfmRQkYNzHmis1o4slO0lUD/eBblxcTA48twa1VwuxW25@lists.postgresql.org X-Gm-Message-State: AOJu0YyVTCxugJHgI8oqVMgYUCL8ZdsqwR4w76KysXxiI9bkTPZCWifz MAGWBFnhKX0sdyWTQpmkCY6ce7rbViBS0EbEojXeYoVD3pPvsi9RY/9egj03z3WU43087XoiEOb K0gWmUVpqiaatqgbd2yBfFJx2rMz0Sik= X-Gm-Gg: Acq92OH+w9pZjui1/3Y0nammwfdYdKhlgQGYap+vVkVl/jJTA9IeKap6Bq2Ts/NP0JS cjyDGLEbPUl3tItWCWnNYoRqwP4MTPMOmJPW5YlhMxkPIKRcFVthgoVp48x3w6+WIMh/4mVl+pY D1BUa1LRIPbHP/emC8mjl3YuGpyiTnSbrTmQSDvhnB2oFi0+RTHNT5yTEkUOIHvncRJB9AT1Efi Ke3ejYirP6bvBthgolI/yPYb6F67l2aY6MhEimRSPplpsHnmSbO4mNuSK74PYfvZYk+CF4fCVjn PmFP8zLn3ihHt26nJD86hMrh9uqwUIHVkqtq6ir4ek8u27F6dzZjDp25O8Gn7a/fNRbBB+dKD9q Ra+QPI6es2JRot0gfCRzJa/GlkSuoBA5/MIiOx5pnICpEZBQxJ34u X-Received: by 2002:a17:902:fc46:b0:2bf:2188:a90f with SMTP id d9443c01a7336-2c1e85c5ae8mr266006275ad.32.1781075921136; Wed, 10 Jun 2026 00:18:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Wed, 10 Jun 2026 12:48:29 +0530 X-Gm-Features: AVVi8CcGXygsjeJOtYJsiqbsBmcznREfaR_z1O8R_pTuuOBq7KvxLbN8BeTsPWc Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: shveta malik , vignesh C , Nisha Moond , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Jun 8, 2026 at 7:01=E2=80=AFPM Dilip Kumar = wrote: > > On Mon, Jun 8, 2026 at 11:43=E2=80=AFAM shveta malik wrote: > > > > On Fri, Jun 5, 2026 at 4:22=E2=80=AFPM Dilip Kumar 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=3Don 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 =E2=80= =94 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. --=20 With Regards, Amit Kapila.