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 1wXFNa-0039XA-18 for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 09:37:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wXFNX-00APyx-3B for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Jun 2026 09:37:43 +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 1wXFNX-00APym-1R for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 09:37:43 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wXFNV-00000001zFF-1H0X for pgsql-hackers@lists.postgresql.org; Wed, 10 Jun 2026 09:37:42 +0000 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c858014845aso2697010a12.1 for ; Wed, 10 Jun 2026 02:37:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781084259; cv=none; d=google.com; s=arc-20240605; b=D+X6UIdWHa/Tr177l1nIlyvagMBNFgjZSSjiwlRft3LfBv9VMaaDL8kaT7MoJgWlaf wll+ntnn9HaufVq2qqdKhlZBtXmhuwxuw6fq6d2+WEp2xRs8SVv6Y/SH+7yoRgNK8etU XlOxZxNsGbqUEZ32LpeHlmgSBthi8wlcb3T/p62j2IqstvmHXsKDQLdMTVUvdyQU1uip +0VgeXfRjG/UlEBGY9ffpuRLiplBIe2F9T+L9IrFR43KOsSXF6hEoKw083EP22RH5N4H ezVEWG1qeGqh8BdIn9nSrr0FVw//Boepjg6ZSYqf/xj9bMPNNmPbwC0XorZfCA3uy2BN 0QvQ== 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=ODQgkif0X+GBTp6J7nPdMz+oL1mscjhByvxqczue/FU=; fh=7cORYU3s+zUtT0dF1nBMQDbNMPBY9hbDVs2phPjUnd4=; b=I61Gi1g5wjpfJSdJjs2Vy/+zcX4E4q017GBahjnO1nJKiYG3bvD2LMatq1AeCGKQ4u OG0ytC62axSzHkAWqPOPJjtpsk0CxCbc9J/scMzOCM8kkysZnnnDQkhEt6ZZhc9U3+6G 4OphcxsCtmCOjjbuIR1FDZM+7al0asQqr2Gxf0PxatMZBISiKIL1b6LvcdB9wYPkrLxX clNm8aB/f5UDiBr2elqUy0lAy6Y+4OLdckqNhwLXxZ2hlSM/pUn4ahpAKtwdmdS2xd39 rdaLPq3nrHXtHCAa7qV29LI0Lg140DcfxHMHeYk5RhwH3q9KxSaxZUwSiL2WtqbxNh81 WgSw==; 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=1781084259; x=1781689059; 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=ODQgkif0X+GBTp6J7nPdMz+oL1mscjhByvxqczue/FU=; b=nrxSKgKAmM81K53lCa82FoyMFrfy6io78lmwTsAM3CPlO6kyCYNTXCiuJeYwhM5uKL UtrUNe9R+Xi+w0BXNHT/KIlnls4wjZMJnKlM4t95WmQFxLLqhoWFvEsAByOFhTdD1//T JKANpitmbvq+8v5RiH8mL+xqpHGTsc7WLSoAd4ll+tBz7ZlK2UFJI9tggOU7xQCJHZyv so7bcfg5ZcOkdNrQQ24I/vbPLk+iDqweqxybOdUoUtUEhxrMpbtanKYFfbUKIflQxT4i U4P9p8R+KNVa1CbZcj4frF2CaeAkghUn6I5Z/CAPfPFkCJLn7hdENSu65Z5QZ5gLR1dU U3wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781084259; x=1781689059; 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=ODQgkif0X+GBTp6J7nPdMz+oL1mscjhByvxqczue/FU=; b=G8qw5dkuCfgpgjzm1u6oh+yNEqk29iK3eDs/SBsoIu2n6Nmr57b5euqqYCJ9BrGLW1 zavyLlXR/DmrrYTkCOsYY3L4TayjlSseScCagmmRPO2iC3xt43AhVpSrKBE8/PNfGxI3 r/FZlXe4IziMCHrBtxHc4vQnjmsriXB7V7xNWaDOYnaZ/4oyMr1jO4c76DyeROK7DK0q M2zh/221joMnx4NRxpIuiypNqMA0brIoVzi+ITHVWWyNkfGuQZ+ZqaFh63U0dHUVUCLu TJ5KDOFNolY+GDIABkKWFf/KgitV+oag9pLP31TKDuxR2+EdwIZcbKtU9qd8/Nqia7kr RHeA== X-Forwarded-Encrypted: i=1; AFNElJ9lG523KWQZkl8vyBcyGTAAoe/5Jg3l4cRwVbKcphZO75NSzx4cD82pEn0QoM8eJJfWgPY4+rrEhOAPdjaU@lists.postgresql.org X-Gm-Message-State: AOJu0YycPAAy9rDvlEk5nshw1uXPHxNmW6Yvy4OyHl3OvaOY2W6qZSW+ UniqpgFUzE2wgvkV60ll0tW9SRyhowf2d9iEvjRSZQcPE0UTHv66JU8W77wUy1ST/HVUKmBDi32 96ioVdCDo1VQBIWsMhR0iorJ2nd9SWKk= X-Gm-Gg: Acq92OELAK8TEfNgM5QNMjsej+3Li9BsvxAVnnUjBo2uMV/bzTKEkIXbVH7slfE8PF5 KCIjztWaTfw2G5ZKLDAArjVL1AIWBWaYKCQdBwsaJPSfKSaAaRCSCQERRxiVMxqRNzaAeLEvbhx 8csVbMMy7ks0ACXixjNx9FKeyI6sGK96u217oD3LS7fnpvpey8SW1pwTPZ968sBV8uFZH67I/qk p1neEisLwyl2+V1PpUB2seZkeCUMJbfL6FfcKCWW8hIaFmvgc9YMhtd8TSlVYJiMpzT/P/qrRtn kYJu7TRvFmcaSltSwqaOZilHOkY+bz4mfygDlBOu9Oa5D7KhbMWyqbXLJd51bQ== X-Received: by 2002:a05:6a21:4014:b0:38e:92f6:9ab1 with SMTP id adf61e73a8af0-3b4d3e083dbmr24015490637.22.1781084258768; Wed, 10 Jun 2026 02:37:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 10 Jun 2026 15:07:27 +0530 X-Gm-Features: AVVi8CewrR2gZO1m8tCMrL-YfBcdVxrZPx2xUOf9bOn0DLIHL60wArL6z8VY1UI Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: Dilip Kumar , vignesh C , Nisha Moond , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers , shveta malik 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 Wed, Jun 10, 2026 at 12:48=E2=80=AFPM Amit Kapila wrote: > > 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. > +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