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 1wZ4xs-000krZ-2W for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 10:54:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZ4xr-00BU8B-10 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 10:54:47 +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 1wZ4xq-00BU83-34 for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 10:54:47 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZ4xo-00000000V43-3b9P for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 10:54:46 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5aa88b4f792so3690176e87.1 for ; Mon, 15 Jun 2026 03:54:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781520883; cv=none; d=google.com; s=arc-20240605; b=O7LNRMibF73eDwpAIDKchqh0DnD9CUHe+IzMU+Ipun9+O20QpLAJjJYEsTfZP5GiFF pqlk25B6X5aVWq9rosnXOw+SBcVctjMR1BrWnjiPI/rejwwUmaFYQIZ2nxla2DP0Edd0 1wofW6f6nrYEkTIAq1EIu8lKGM3X4rEh7Xsy+figpkWNZNjleYZ8lPf2X/5UbbrdDbaN dyiijW+j3vtC7g+eoiaOImYx5O+pY6uoClUdQQMwfXiB1m5lFfDs8KkbMYUSlHgSBTZs VJAspj9NXEMXNyEy7/hz4ci4q9tjQdPXnrUQLZfTluJQnx7/3fT70Agr9a5y8arNkeP3 EJJw== 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=ERh4s9g6JMuTRfgBwniheQ9ICP0JGQLWRwgQgWI3CJs=; fh=+tXbTAuGq4+5i64q64HC4HgD8hbesNFBX98D062wFA0=; b=L7BJUvOHKOLKyqr10Tf8B1OPT3i++UxiEYUkJjRG+L351SFHDu5admBc8Sza/w2zX/ lc8bqTtBdQMSb4oglCq9Nu3whN8OyseAcY9XobKK/VQXNHsiVbIBgD/kTIYleiBu7Z1E XXNiogIzGNvTnX0nGxpWOc3TDQqP864mTdybox0mG9yLWJrAWOi33FHCz0X8IhhQp+fZ xa4naIMbU5VEjpZ5cs0Nv67Se09NpopXHxHwX/VNS+5AuECv0pn5M2GyAL8gkj2r4dwV NsCiWt1SwAf1ewxEctvRSaJ24/rAnMm8/Vvkbt7YMQ9OP1YUATjhDt5qoqz2OCBO2JWs OHyA==; 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=1781520883; x=1782125683; 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=ERh4s9g6JMuTRfgBwniheQ9ICP0JGQLWRwgQgWI3CJs=; b=C23zenxJV2givr+PbWfdamB8DNZv70qdvv3nxYNEG8stk7zLIBcfqdGu8KJfBheL+K zIFM/CH1Cixz9bPmaOBFg9FuF+vB6jlu8W3Go0EJTHryyhvXajEi+G3wEExtAuMndKPX +sHmb1LT4qIOcz4ViSNk8Gtl/fyc2HYqoWZR7np/9K0GLXKYkbtCwA4kc1wc/BNJX4hN nfR9Orna7PUvYUKDjXF8ovVMObrqYl0ZuOOXA8mEI7+ROO0kMaUokTnmD9ca1HZt+gNZ iVwEA7/5OZBHsWrKVvoTecXDRwBM6TPLVgxZUE2buj/ZojSApNhvzIR4KezJVpdfNw1K Wp/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781520883; x=1782125683; 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=ERh4s9g6JMuTRfgBwniheQ9ICP0JGQLWRwgQgWI3CJs=; b=pbNVSr0wof5/AxGuzv8OJQc0hX+BgukV5vFWjOUPV32go2VrugReARX8uy2qcVWX5C VOaK/uCXF+MzfjjkUewTd3cPmW/DkZBugdfcPuVaIz2qkJ9fmyyEWAS5QB3TF+mYJmRq rzzm1ahAaaqaXt0gil4Pm+C2YI5C6Hr21ITv92xcvjqthThiuA77sR8OLlt+yaKP5YB/ t7NwQuS2oGK/D81HZY5+bvTmfQtaCDmpICcNu3dWnExyUVtnXT7fFslp22CCMLGspXeB g6jtHNpW6V+ttugJqN6NO+7lfSHfgVrgXtD1nEKOV8UEVTJKjsbHgB2ka+y83kJPqIKn DLnw== X-Forwarded-Encrypted: i=1; AFNElJ8mpkwgcfChNzU9aqy6nYt6ocgow6knkef01BFu1nkj+XH2SFV6XBX9ou0KXgd0nZSr6PvWurRH8VfLSchg@lists.postgresql.org X-Gm-Message-State: AOJu0YzyRuae9fIZzXxwzK2Nv4AxeItu0/1HDvp0mR/X3QG1IqkjqaZq QdP+ukAJ6ttSGnevlF0tMJxuNqHThWMgricQYVL7ktjheMhlPbjd+MhwhMQtUy+RcURUTIGKiqv NBePeBMMx1SPH/zlZq2DwxspXDMjoPJ0= X-Gm-Gg: Acq92OGSDBEfdQrmvQICDF/nLB7xde11D30PRcWD6FhxAV4nlmzZsghNiwFkP+E7IPe q6W6tPGbg2iewUXolXoUVyPhImtuXBOvrjJhWEDPw3WVShQ/TNPTAjRfRsGDa22CURjcL27xnNW JCxwzkrl5uEvDbLAPox1vq+blSohJHBHwx7GhV1b7YTUS8TANI4fB4Pr1Ry3sSQ0Sk6lFITOu29 wwsCeTrQlzl8MGJOFjQjzZTF+YyGfgOpDMBw5WYAtHhFUscjZmmpBYEU5Kl2rSiagwkau7+tR13 qkZS12W8 X-Received: by 2002:a05:6512:39c2:b0:5aa:65a3:468c with SMTP id 2adb3069b0e04-5ad2e10267bmr2880521e87.7.1781520882415; Mon, 15 Jun 2026 03:54:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Mon, 15 Jun 2026 16:24:24 +0530 X-Gm-Features: AVVi8CcTx_-5QZrKrKylNOL1M4hrqwZjEZcfVWZw3ZSXoVP62_czRlZdxNpmaMU Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C 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 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? IIUC maintaining the conflict log table is the user's responsibility. Therefore, we don't need to overengineer use cases where a user concurrently backs up and deletes the table. Furthermore, since only the subscription owner can delete data from it, it is ultimately their responsibility to ensure they do not delete rows they intend to copy. --=20 Regards, Dilip Kumar Google