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 1wYySi-000fat-26 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 03:58:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wYySh-009eAx-1s for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 03:58:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wYySh-009eAp-0h for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 03:58:11 +0000 Received: from mail-pg1-x529.google.com ([2607:f8b0:4864:20::529]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wYySe-00000000S5Z-3aNq for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 03:58:10 +0000 Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-c85c531d4a9so1048033a12.2 for ; Sun, 14 Jun 2026 20:58:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781495886; cv=none; d=google.com; s=arc-20240605; b=ZQlcWj+fWinclIupAMZk9zUXv+IShZxqXbXD0/U7eOazBKm4/nLG+Zh1NTWHgYq1AG xUVaUPeDU2otdIjh7otOSqvZdw0wcoTKwHtCJYrfhZfQeOQMnA8vraYkkuN4Wib4/Q7N wy1f+EKS9XajqItjtP5zMeXWqeMD1JNa1KdatIX6ESu87NoR1elpsNm+J54hS9IoL44X yWkS9go48idWHouTzq9I/+jUzcP5mfT90NovndmJorglsm1qi6N/Z+dHzQ4P9RoIXR3c 7ewvGWmpNGBhjy4Gv5+SL+J5WS6gKLJZWdqbl6kweMrYTOQyzpVCmb2G1SYkBqcXhJb5 88hw== 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=Ly9q5cDsHZ0RWZnLFCTImqDN4PWffGjKphLvhXEefoM=; fh=16ByyoTvGe6XdBacO5D23aJJIVscaWMKTL07opghDTM=; b=aSds75+tGLcJzCIc0kp2pmyhAyJ7n1rgvmzJDXWBAQLLuqNKU9KTqeWff4l9Y04wGd i4dT1a31F9li59l4x5+yKi9jgyaQjFvilgguSEoD6deEdU957U151d7aDndvFrPotTSx vldN88Il15SKLGV/AU3HNcLNhu526wH7x5PvSlxhcYlXEUKoBq0nxvLuNJqBsWCNfihS VjPBWp7rfTXGCQXPwdd676O4RltBxKmDLPH7a/rFZsVOddbZa/SMv4TmVP1A8uRuQIYm toEwu5KJEDA9iYtl07wBiMtkWRmw2yG6x33BuaJmoRXG08mj3pYhXss72nVcGvo2ISDt HtFQ==; 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=1781495886; x=1782100686; 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=Ly9q5cDsHZ0RWZnLFCTImqDN4PWffGjKphLvhXEefoM=; b=c7bnjd/nWi8W28Wm/2DgyVz7UrR5Cc03pmbDsL05hNChBUb0SnBM+keN+NBDIMWt6g roqV5I5PsP2U2lADZEpEQN1ZUKlDfUNDzx7TOWlHefcngyPjQhx1erww29qO6pdrV6Oi S5BmN0aHbD+dq8GXW7v6dkAGo8MNCShpDLnBeF/XaI+2sbYao4c9371vf0szqs/2hR08 NWM03RypzrwjMzMxYyK60uVTWz9v4rFqGVxI8l6MKTJ4NgPYRLZstkf1WHVycGCeB3t5 /GBVyxGMkLECxgIcLc4RN4JrWPoQ91uKOc41GulleuEw42+7HcorGj23vC0Z9AqQ/9yz V9jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781495886; x=1782100686; 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=Ly9q5cDsHZ0RWZnLFCTImqDN4PWffGjKphLvhXEefoM=; b=Wp1HGTNQu17cFNwu1mlWBwJSJyVdkzIThI2Uap3b9tEdCLE2V2oc6CeG6yYFyxx95n OPAkAMeDXtUnv8P1tLgAnVFw5X02CJXs8VddmHW6dEY+l19YsveLVUDY691+84NVKp1K 8V01RV7s4scxHLeXyWSXvdnBSo2CUfXvb4aZaTbPuUWuY/HMMboIiCOpvC9I4jeiFZhM k8WexnQobN5SI0iMoQHJLxWiqEdSbMQcxt07FIjDWSWxxVuFulkfxjmJGPquLhGjLKwX ljGN235ZMKsaQ5zj0k3GNFO6C7v1nTlUsGKu/P5md3ox00h5B9XmDQHTEi+OxPCbU+8G ZksA== X-Forwarded-Encrypted: i=1; AFNElJ88uRu8nPnAjKNFbOd4ZFhVggJYqjUZmLcn0qEc5m3AlhrYGhlEEBO9cul0TIa+HmOOnsaavIHHKEkTndtl@lists.postgresql.org X-Gm-Message-State: AOJu0YwvLreoGU/iPmi0dkHukp1+4ikjy4spOHAZ4l5e+ERS2+A0Fiqm V4PU1JUK6b/O25h3PdahqzC0dkpbqlM3GpPXEqC88fozr70zazdpK/FonF3aXJeyrG6H+R+lxrS cjscoG/jMm++764INBfPku3IGiqr5oHA= X-Gm-Gg: Acq92OEjgH47N/SkYG+1BzhHdu+HWmRkJfWZikB3EkoF/+3hBexCbmSXiQtwN3SCXxw 7kQOSzdoDDzLMCYY3cHVFF61gjWZxdYWzzeDqmGk/eO7WNhNrfoZjra5LlEmD643HS3prBuWFoB tAn3/WxHVq7zmNOzrDB1LqM6es0NtHLFRyUDAI8Oj+SpWVyzrSnzkv/Gt2XvQItYM0L73Z6lL6o r8dx8kTlvz9XqN67mhpLW21daltH4V/Mfd4TDIfkk+LprJ9YxGuf9VGJkCB6lnt9I5bAn/vFlD5 SOhgtf05jfyXsyh17OJVovk92DHbnTdFtpZknLYulamVRoFTJ4Nz5A== X-Received: by 2002:a05:6a21:6117:b0:3b4:8e36:5fb6 with SMTP id adf61e73a8af0-3b7962515d6mr10199142637.2.1781495886146; Sun, 14 Jun 2026 20:58:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 15 Jun 2026 09:27:52 +0530 X-Gm-Features: AVVi8CfOndNeQNo7zmI2WqAuTxJm-RXlHgkNQeAU62LmoEyfHKmY0vUpC1pND1o 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 Sat, Jun 13, 2026 at 4:58=E2=80=AFPM Amit Kapila wrote: > > On Sat, Jun 13, 2026 at 3:46=E2=80=AFPM Dilip Kumar wrote: > > > > On Thu, Jun 11, 2026 at 5:53=E2=80=AFPM vignesh C = wrote: > > > > > > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar wro= te: > > > > > > > > Please find the rebased patch > > > > 1. It includes the new 0005 patch for reporting errors for DDLs on = clt. > > > > > > > > Open comments: > > > > 1. Recent comments from Nisha and Shveta after v47 are still open > > > > 2. Vignesh's patch for "describe related" changes needs a rebase. C= an > > > > you do that, Vignesh? Meanwhile, I will close all the open comments > > > > and try to share a new version by EOD today. > > > > > > Here is the rebased version of the patch attached. > > > > Please find attached the latest patch. I have reordered the series, > > moving 0006 to 0002, and updated the lock restrictions. We now allow > > ACCESS SHARE mode exclusively to ensure pg_dump can acquire its > > necessary locks, while blocking higher-level locks to prevent > > interference with insertions into the conflict log tables. > > > > + /* > + * Conflict log tables are managed by the system for logical replication > + * conflicts and should not be locked explicitly. However, AccessShareLo= ck > + * is allowed to support pg_dump, which must lock tables to prevent them > + * from being dropped or altered between fetching the table list and > + * performing the dump. This read-only lock is safe because it does not > + * interfere with concurrent insertions into the conflict log tables. > + */ > + if (IsConflictLogTableNamespace(get_rel_namespace(relid)) && > + lockmode > AccessShareLock) > + ereport(ERROR, > + (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE), > + errmsg("permission denied: \"%s\" is a conflict log table", > + rv->relname), > + errdetail("Conflict log tables are system-managed and cannot be > locked explicitly, except in ACCESS SHARE mode."))); > > In favor of keeping this code simple, can we allow locking the CLT > table with the following comment: "Note: Conflict log tables are > deliberately NOT blocked here, even though other direct DDL on them is > rejected elsewhere. pg_dump relies on being able to take an ACCESS > SHARE lock on these tables to safely dump their definitions during > binary upgrade, so we permit LOCK so we allow LOCK on them and treat > them like ordinary tables here. > It's true that a strong lock (ShareLock or above) on such a table > would conflict with the RowExclusiveLock taken by the apply worker's > insertsand could stall conflict logging for as long as it is held. A correction: It would not only stall conflict logging but would also stall the apply worker (logical replication), or is there a default lock timeout that I am not aware of? If there's no such timeout, we can correct the comment slightly. thanks Shveta