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 1wYzhP-000gY8-2e for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 05:17:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wYzgP-009nMr-28 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 05:16:25 +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 1wYzgP-009nMi-0N for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 05:16:25 +0000 Received: from mail-yx1-xb131.google.com ([2607:f8b0:4864:20::b131]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wYzgN-00000000QS8-1HHQ for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 05:16:23 +0000 Received: by mail-yx1-xb131.google.com with SMTP id 956f58d0204a3-66077e90382so2269906d50.3 for ; Sun, 14 Jun 2026 22:16:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781500581; cv=none; d=google.com; s=arc-20240605; b=gieYIwVnSn9nEPf0m8jlPrIfzspeymXorSGt0wq1x94XG5adzn6sQPBTU6mFBpaY/n mC6mnEJ1NTx8FFWo450vrO7QjwjsJu7EfpMY/SY3s2NdaY6ocQgQ1eJ3gbfyGeB3jEj9 6kJw+4KeaK7LpApylCcwG+uPy2eRxbfM71lkpnD//hTaCfUcoGkJSeTf4MTVe/VDHgRZ +PhesyRreOXm90XaXSCzRaVoMi8f4M+s4+HdGtGhF6wnkQPgNNcGcRSOYrk8yy2D7Dcw lEnTkIATEgbGCtFJpkWDsY5pgFEE3UerRYLP55rcZzLaKWQi1/iX0Zf39gWrzTAHbXMd xeuw== 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=Fkpc6a6jtUDBWKziuIsOr//cnUhX+JXsIrmKOEwqNZM=; fh=59VhmNQTFB1Afo5pDGVS82sLWPCK2NesOj7Cmwt6qnI=; b=KJ8JhQ/q+jMf8Vg4VOduHAfpuYF5GjVAeLrX8K2ceAw8I/Dat0WeBXc0rj4u7ZCnz5 tJlifSize7lULe7cSLv353m1JlZ+nNO6cWbLPCs2OHEWoDPrEBr6JPc4xHEucuIIeipg lSEJQftoodMnooFGEixFfvIJYv1EAKUDLrnkrGuidc030HsJ9QoY6CxFLFkcntpSWJEy AHnWsXLnXEhrSCjSqk/E3tLuh+PgRR9hyq08KdFED9k3nUOBrOSGcrsReGrq2q/cYJn9 H8UE67lxAiymzihLtNPDh9EGpdTK1a/GJm83MHCk+qMui9tVxM7aekM0tM4YU+2k2tWc Ca1g==; 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=1781500581; x=1782105381; 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=Fkpc6a6jtUDBWKziuIsOr//cnUhX+JXsIrmKOEwqNZM=; b=LGccGlQARDnR3WOne0syD6AnaYQtKlA23moFXbKecdz88eTWyVmzNrUptiCIzXlEZ2 qlDw4BMWeHqkOYRgIpeG3yHz4tpFEUU+70e6lnXhPuzNIdMjFtmlJ4r9nXWHGLaVHzAJ CGp1NS5VxCI4pj8e9YuuXCwxqQm3yScBMLtgfxq8CTnXFeT0t75SA7EQbqX2WroEcB9W rTMe8FX+4GA4TWvoG0kU6zvvh4kuSTg8nVXHdrtCmp95HCmqcYPIDALZRDl3uY5vKvBH 6kBu6/b1w9Uay42e4SzFgbmi4f4ykHBzcQ0CgYKeoz5jYaOhRTU+jn+DDyoJIYWuERCW shPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781500581; x=1782105381; 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=Fkpc6a6jtUDBWKziuIsOr//cnUhX+JXsIrmKOEwqNZM=; b=WoFI5wVmb7qRDKYvvciL7GBcHObHKTunjPwvDak+DqCpkvpDP+zDmUVOUWGZ7s74/E sirEeroUx80k6ySu+xL61Q79tti15KL2vWJdVD+Dhd69zOSc+L2ulL4c/+XbyZxsL231 j8ATaXHajfgC4gdYQHh33bxO4glfudduyfGdPiPRca3DzGzfTuIed+ma+6qTlpgASwm3 zU7ABU2rYcZsTuH4TpGGQhcU87bnuPM3arjOtNDXhjjzx1ce5IEKbWxsIYr0RbKsg43P fxMUmkOSirS+z+tu0/FOmp5zjPm1WYbR7BOl889pu+C0knhnh3FqybQxZXVEAxIXhR3/ 11Bg== X-Forwarded-Encrypted: i=1; AFNElJ/dOjdsZi2phI4RQ75FEz8eSKpk4CtMK/6z2t9e/1Z+clQBmE16pE9T2MdheFR+XxvatX5Rc1rS8ehsysG2@lists.postgresql.org X-Gm-Message-State: AOJu0YxrBVA8pQ7TTP7ffoEicdkbcP+ZK8JRpN0M0c+1Eg4QmU+363iE fcUQRWNVlI8fOC559zsIdcf0JVb6EfRGTVr3woGhk3WM01Oa4IfR7ah1qm5+wbFTpbppD44mnpp W0arWr+gd5sdTJ2ddg02lTgc+zL2MWtE= X-Gm-Gg: Acq92OF9F6v4rJgkq8/7SRFflkKBFerV/reOG1tPsSReRz0nEUpuIlbwgY/CPttkHsq a8utBfqDco8EllH/bhvJ9vH/usxOiq6262nGeDHaXtQkej8vk/twUhEv5a4V3JCYm/B0sx8sKr2 4dKmX1MFwSqJaC3rBH2lW3L9/imJu5Z1N9v4wbQLxFB3NzsWsqf9vpaJqMXAawY0fc6yqxwoGQs 56ORhj8ZDFXEEzkUfQUIYr49RosD/NEgtUV32HtmE8V9n7Kak4SFFW0u/QHuWK/SK0lEEj9Nqkl jHZ/BT7s6AN6OktnJ8nY X-Received: by 2002:a05:690e:1917:b0:660:ea2f:61e with SMTP id 956f58d0204a3-66277f22ddbmr11124580d50.6.1781500580381; Sun, 14 Jun 2026 22:16:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Mon, 15 Jun 2026 10:46:07 +0530 X-Gm-Features: AVVi8Cc2YzK8uUfll3dYq5-o7m4bj8kClcZqKWylKXsxKlYShdcCKe4zWoqoMy0 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: shveta malik , Amit Kapila , 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 Sat, 13 Jun 2026 at 15:46, Dilip Kumar wrote: > > On Thu, Jun 11, 2026 at 5:53=E2=80=AFPM vignesh C w= rote: > > > > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar wrote= : > > > > > > Please find the rebased patch > > > 1. It includes the new 0005 patch for reporting errors for DDLs on cl= t. > > > > > > 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. Can > > > 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? Regards, Vignesh