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 1wZ3Ak-000jTj-1l for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 08:59:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZ3Aj-00Ar1Z-0m for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 08:59:57 +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 1wZ3Ai-00Ar1R-2J for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 08:59:56 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZ3Ah-00000000S0i-17yw for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 08:59:55 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-2c40397e3caso29206015ad.2 for ; Mon, 15 Jun 2026 01:59:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781513994; cv=none; d=google.com; s=arc-20240605; b=GzptIJhTHytk1JFAMQvls17HlJw4EEpFVmzYRh14LrvXemBBwFO8TeCfsI7glpbPdr +f1K1cjlpi6Vn9PPpVwXja0BTEAb5hc1iDEZtPBbVyBFLNYholYgkyxwMzdASgwPc/w3 PSTyouR0Ls9lLJj3DwAVTwusX4VewIEiNtMRUejmwSK2HoE6eCPXfEqB4Zgg/Kp0zEPl QbjKY0vBeKnB0uQiYLyvtDqt3p2gimbilOxUPKc9wRGSzDUlinOmt+5f2m/9CkLKqhC8 WqdzUeZV+LaLBqDu5jUjGKPCOKs9StanZvnyAlPNQSVCT1CJp2s6rIazQNOZZ3+DMmeE l7Xg== 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=aOM+uBdcZVoULHXU0CZimbyeEu8KtWrbqN5WRuAa5Uw=; fh=DF+8j1ZHg49BLePKZBnoWIKRi/+oII/3cTOBh6g24z4=; b=GPc6P87mdJ66yq1lmVkrW9xyRLSEbm3pR8ydTh1G7i+/UQKRLjOUCwBCQs3PkMIOY0 uSkCoM3sZUASHvuIvfzx1UDEPjl70FaGEfInYLcz1LUOu59zc5YMDOSqkwkOQAdszlY1 AnjemA2+0GyMuJtcoEJslFBztC8bFKt3kJ240snvgmBsxZu3LA4e/82scQN1Jdqn26B3 +L8TofSM0N10JYCZ/smeAN+wdhFz7L+t/wUgunz+Wmz7ynd7t4Oixk4cVAc0bo7loTID MvLt7Cf6i+i5FA7gIjWjygWANuOPSKIwSf2zM8+Z/q4QJRpZ1ZTa8dv1nvLcIl7kklEB hS2w==; 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=1781513994; x=1782118794; 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=aOM+uBdcZVoULHXU0CZimbyeEu8KtWrbqN5WRuAa5Uw=; b=RExm6xvgxh69gS0089qk/5P7UTZRQg6iUA6kh9ozKjwt70EWvE8/m7JwSzfSeX0MXP gB87wfMvXFX8jYPDES2+mJ8/oIa4v+ThsEncynuKL6ZoAdhkckLhDHMwUu7wGUVOEUr6 IbOpSzYNUEedCMBXhjAKGpn5hsgARrw9vAJJ/L9XzxcfWNdXyvYpXRkV6WYdfXFlxbXX coCsA/px7ZRerU9z5Oq41DelLDJgWFqzlGluoFzdixgGAsCwzSdQj7oYiWwt94tvkIyG KhBI33jWUjFLeJiwRDJI0j0sHvEVhabY3KajJabNnoNtzsqxfroRcUBQT7LDrf1doDl6 v1sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781513994; x=1782118794; 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=aOM+uBdcZVoULHXU0CZimbyeEu8KtWrbqN5WRuAa5Uw=; b=AE7SNYfdWN4DW1AUQ+0h8+0JRnRs8gNV4HHkb6q5b1LGhavSm7/QXbKZDNXtjfjaN3 DEBrYsSHpInugJ/qViB059PYU0txz5zaZjOWIisIbRwuFIAtTr6qvsErI7EHCmsLZu1p VVXDlLqfkqiQKv3Mp2M7Z6YvSPhEGC/5nIXVaiTzpcpzmnZqqwdbSFuE7qnpYqrhCe68 0YLBs0rnaaw6IdROBiCcATgDSdirG/JyfsIW5N2I3l4fPqyzM9HFFXY5mXx6kUfrBP8y nOSH34hQHM9f70Ebmxr10p2aW961n1vIZfjrnW3ejsTZiL4Z3w92z3lVFhJs5aOhqzcS /oHw== X-Forwarded-Encrypted: i=1; AFNElJ+BpTa/oz46i2LIXHGTv8SQT7xewPZpamtJgyY9iRQd7ZnTDNgimtD5zyu1YFnnUiCmgwweljbglPnQ6U+H@lists.postgresql.org X-Gm-Message-State: AOJu0YxNwIEZmCeE0raiNyk965PvCh5b7fvBDF/mbT1lfFO4jhGJYpjc yIIRZTUTQJn3NMRKYWkzV61qI/yxq3QAmvRcFXcf0rWPEnJD1gcbINvpEoDUECPiXTNWr7c9BCC 1ctTXCEEnEl3xjidQY0Ebq/lr5XZB0kA= X-Gm-Gg: Acq92OE1lVE+h5nS5+72QugubSKDVUuGceC1mYg/xMl6qK10uSUcnMztiLbupgPNRWi kh4MjgYXdrdDOEuP8ZpheVkEUbPGuQtA7rCb37LUSMBeH2eat8tC0cKH40Ao2MdwEaY6XByMjll REOmPotoEHCU+kXIZTGSZOYV2Vb72p74X6TDS/xeuaceIx8z1Im3I4S9TVzPyzuhD9HYEtPrIpm tT04TKea/tNPieJfdg+IMRWWJBqfX87gUVdmPqENCe4guV2ZPpzEwsOkc5XF22sxlBZstzld79u y6zjJ5MGCGu7pZoHYDo5c1lTbEumLOz2JGQnX+MHU87v3y7NXG6SawjTFDIRqUcm8q5hjtsjurA teazb9l8EF2WLa+h77A== X-Received: by 2002:a17:903:2ec5:b0:2c2:1e6c:450f with SMTP id d9443c01a7336-2c4109ecc31mr152968705ad.10.1781513993841; Mon, 15 Jun 2026 01:59:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 15 Jun 2026 14:29:41 +0530 X-Gm-Features: AVVi8Cd7aon93dcP1i8lE2vlM1DzlS9BsyQoo1EIBDvOQxigdvYTsHnufsmaVTA Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Dilip Kumar , shveta malik , 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 15, 2026 at 10:46=E2=80=AFAM vignesh C wr= ote: > > On Sat, 13 Jun 2026 at 15:46, 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. > > I noticed that declaring a cursor with 'FOR UPDATE' on a conflict log > table currently fails: > postgres=3D*# DECLARE cur1 CURSOR FOR > SELECT * > FROM pg_conflict.pg_conflict_log_16404 > WHERE relid =3D 16402 > FOR UPDATE; > ERROR: cannot lock rows in the conflict log table "pg_conflict_log_16404= " > > I'm not sure whether this restriction is intentional. > > One benefit of supporting 'FOR UPDATE' cursors is that they provide > protection against concurrent modifications. For example: > **Session 1** > BEGIN; > DECLARE cur1 CURSOR FOR SELECT * FROM t3 WHERE c1 < 100 FOR UPDATE; > FETCH NEXT FROM cur1; > > **Session 2** > DELETE FROM t3 WHERE c1 < 100; > > In this case, the 'DELETE' in Session 2 will wait until Session 1 > releases the row locks, preventing concurrent modification of the rows > being processed. > > This can be useful for workflows that need to archive rows before > deleting them. For example: > DO $$ > DECLARE > r t3%ROWTYPE; > cur1 CURSOR FOR SELECT * FROM t3 WHERE c1 < 100 FOR UPDATE; > BEGIN > OPEN cur1 > LOOP > FETCH cur1 INTO r; > EXIT WHEN NOT FOUND; > > INSERT INTO t3_archive VALUES (r.c1); > > DELETE FROM t3 WHERE CURRENT OF cur1; > END LOOP; > > CLOSE cur1; > END $$; > > Given these use cases, should 'FOR UPDATE' be allowed on conflict log > tables, or is the current behavior intentional for some reason that > I'm overlooking? > As told in the previous email, we are planning to allow only a minimal set of commands initially that are necessary for observability and maintainability of CLT tables. I think such use cases could be achieved by LOCK command or the user needs to be careful not to remove/truncate data from these tables till the same is required. --=20 With Regards, Amit Kapila.