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 1wbJ4m-002Rfo-38 for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Jun 2026 14:23:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wbJ4k-003Q4A-1g for pgsql-hackers@arkaria.postgresql.org; Sun, 21 Jun 2026 14:23:06 +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 1wbJ4k-003Q41-0S for pgsql-hackers@lists.postgresql.org; Sun, 21 Jun 2026 14:23:06 +0000 Received: from mail-yx1-xb132.google.com ([2607:f8b0:4864:20::b132]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wbJ4h-00000001bdb-14Gy for pgsql-hackers@lists.postgresql.org; Sun, 21 Jun 2026 14:23:05 +0000 Received: by mail-yx1-xb132.google.com with SMTP id 956f58d0204a3-662bf1dab83so4103715d50.3 for ; Sun, 21 Jun 2026 07:23:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1782051781; cv=none; d=google.com; s=arc-20240605; b=Iew6eM2dKqApt6FKjyeHWztQTzVtz896DEPK3pcUxCgyfP94BfEAWUjzMEKbuz7ceE CXP50925TT3wcDBqh+GkzKbfvAFC8+vh81Qgke4Wmkax9UPW09uIcujap6UlLSnx6ntq zG+uo1xnfTNdpWdSZsplXzdv/BM7jUuAnv22ITJsHdOa0C3oG2xUXI9/QeReEzj0SFVp ztRvvFV4UGBZF2uKgCQJ6ODequwy9oapIrWPpQqL1OkNE6SXBHqIVH1NR2NRETggvnCY qxdpaYIahJ21dv+3cKnvaPgEble1cpjzBc05z+fnk7gC+tfyuReFt0EECYiBZuVvOSmd F4/A== 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=euR65+K3jRYVjVW6gG8f2O+nVmM/iXkPPXvMqV2Z8xQ=; fh=bQShkk+899IIf89ZrPShMRIJMP5AdY8R3qzez2m7dO8=; b=RcVvj3AZL36sVNmjF3Viqm4k1FDFeowKvP7SFT7E+vMTMSoNnrMC4QItM+jBSVGFI0 kYLU4KVTlF9hk4L+vEgBGXq8C4KC+I/GKk0P4AxgfrZ98YcuWAJBh8O5JeF05p1DtHZI /B/O0MQUiBEA0fIWUVeZZcSmC5WZi2vM3jKG1lO3zIMrLNUsDdiV4IMAXDYknMMlulCE /r32QZkDybrFi2qq81W/r0fGuIRlc+JxrryXo4c8QNCx6R9ZSj9FcCeXnE5IrlOH7e7N Lm4vwfh6D9A97Fudlp/Hl4X7WM60Vnp37tPhAHkQVy+Z8QjpJr8ZAYiu/vDcyOgxgnws VZ8w==; 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=1782051781; x=1782656581; 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=euR65+K3jRYVjVW6gG8f2O+nVmM/iXkPPXvMqV2Z8xQ=; b=XG+H7x9eMt+yzAZd95nSi7Ny8sg7MdkwHpY4LiXcRVxk5KNxFekPd9RDUaUbMyShCe SVAbpSY+o0BVx1Z2RGPYguJLgzGHQbJZNUu0gtNiFpv7/58O7K+fIwtYNt1WYzoATmAB NDQsJi250pWJjQ+Mg3U+duTvClgvACXO551pdMRo0/tGKhTuCIvM8xFOw2jNU5YCne+G kkDgUD4qRzyCzlaEFVdhOkshur7HfCVQgXbfH13FEOLE+Do+dJZKwqr79HbYr0jebev4 no4HDbStAkH/HtD7o8ZQXJTuNRtEyDRdIMQ2n/vD7SkT3b6T9TTDcS1hWxJGi7X98/90 o37Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782051781; x=1782656581; 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=euR65+K3jRYVjVW6gG8f2O+nVmM/iXkPPXvMqV2Z8xQ=; b=GG1nmg+Xn5cs2FC7iNI5l22tUzXUg6ncQY71KpcSAHO8f+gOH9l7rw8T9Ey1ZMerrh JZa1ardR91QE1zyaM1o/sGgULcFiAOxnlTeo9CbBR+2doSzfU5a8HA27qoEezvxYpH9I 4K+M6Fwa3Q1v2noTvT054xHuucrcyKAHJhGoa5B/iCKOkZFcHFoFqsE5X1j2s0bi1geI kS1OYqkm2bRQmABVeTqtQPtY4acanwiozAjtJxmiYIXK2CJXbE3hr3yp7a9vLAZTZhxs qv8tFkS1HM0L3ZoJw6ZF2o8IgXcF4kws7inZ9TDo+p8ZNHrOXmrPTe5emhADXyb3nPzd nK1g== X-Forwarded-Encrypted: i=1; AHgh+RrnMq5HVrN8Ec+jrj9mSlpNTQe0R8NQ3RvI8vKKUKKXRcLUHy3zhUHh03+l2Ip0YJ9M4LqdrEsVo8gbC5V1@lists.postgresql.org X-Gm-Message-State: AOJu0YzznlE9jpluxf+Y6QbUOe7b9s0KMJHIUuygqcAQOBNZ6PZUvQhJ oJ+ER2OVNnAY81VOk5R+RSMxX5QbH5dEhTGDK5c0MYcDSvY+0d2M0TLxxMVh6F485cVGkudOdoH lXREj42se8+cECqazX3EGOdZq7KW7908= X-Gm-Gg: AfdE7cnmRE7x0vVq3zONyQz3FQbl3FKRd8YSYrcx+azWHngpTTQWMW7DdoYx9tWwCtO jSptTk1VnWUH8aGdMxLilONaISLG9xBeW8T+j0nDt2nw+Z4/dFE7mebPTkglHS6CS9fRIW3BqoY xupIXk/h6/FX9OgH0NdKlZjzGPo2+vaYaixB5MNos50XXWkLi4ywNgojHSL+ZG+qyBlxBOexNR9 HTgeZDqOlwvMt7qLnCPJR/cDKFgiCNSFUMzooHJJtGhMYvxGi/19TSJjZnp0+jTwwYv6fpoAVc6 voEGI1VMB+erRpDPPRVQwrNZ5surDA== X-Received: by 2002:a53:d102:0:b0:662:80f6:440 with SMTP id 956f58d0204a3-662fca67239mr8771388d50.46.1782051780920; Sun, 21 Jun 2026 07:23:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Sun, 21 Jun 2026 19:52:49 +0530 X-Gm-Features: AVVi8CeP-oAqrX8w3ae9jE4krzOHFXNyIj_nF5-sNUUKfIKqzxAdiub5PvkLW-Q Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: Shlok Kyal , Peter Smith , Nisha Moond , Amit Kapila , shveta malik , 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 Thu, 18 Jun 2026 at 16:54, Dilip Kumar wrote: > > On Thu, Jun 18, 2026 at 11:29=E2=80=AFAM Shlok Kyal wrote: > > > > On Wed, 17 Jun 2026 at 18:31, vignesh C wrote: > > > > > > On Tue, 16 Jun 2026 at 05:19, Peter Smith wro= te: > > > > > > > > On Mon, Jun 8, 2026 at 9:39=E2=80=AFPM vignesh C wrote: > > > > > > > > > > On Fri, 5 Jun 2026 at 07:59, Peter Smith = wrote: > > > > > > > > > > > > Hi Vignesh. > > > > > > > > > > > > Some review comments for the patch v45-0004. > > > > > > > > > > > > 4c. > > > > > > IMO there should be a separate function for handling the subscr= iption > > > > > > footer/s, same as there is already a function > > > > > > addFooterToPublicationDesc. > > > > > > > > > > It is not required in this case as we don't have multiple footers= from > > > > > different places to be added here. > > > > > > > > > > > > > Sure, it's not "required", but I think: > > > > A) Separating the footer code from the non-footer code makes it eas= ier to read > > > > B) The 'describeSubscriptions' function is too long. This would mak= e > > > > it 20 lines shorter. > > > > C) Consistent footer handling for pub/sub describes. > > > > > > Ok, Let's keep it consistent > > > > > > > ////// > > > > > > > > More review comments for v50-0005 > > > > > > > > =3D=3D=3D=3D=3D=3D > > > > src/bin/psql/describe.c > > > > > > > > 1. > > > > + /* Conflict log destination is supported in v19 and higher */ > > > > + if (pset.sversion >=3D 190000) > > > > > > > > The CLT is targeting PG20, right? So, that comment ought to say "is > > > > supported in v20 and higher". > > > > > > > > Ideally, there should be some "TODO" reminder comments here to ensu= re > > > > the appropriate 190000's get replaced by 200000 as soon as the vers= ion > > > > number is bumped. Better to flag/comment all those places now, so t= hat > > > > nothing gets missed later. > > > > > > > > (A similar review comment probably applies also to the pg_dump chan= ges > > > > in the previous v50-0004 patch). > > > > > > I felt it is better to mention it in the commit message of the patch > > > instead of mentioning it in the code. > > > > > > The attached v51 version patch has the changes for the same. > > > The patch also addresses the comment from [1]. > > > [1] - https://www.postgresql.org/message-id/CANhcyEUjc9TCcW1YAQVMTs6-= huWBZoy%2BsVkz5C8b72os5p-f%2Bg%40mail.gmail.com > > > > > Hi Dilip/ Vignesh, > > > > I reviewed the patch and here are some comments: > > > > 1. I further tested for the object which can be created in 'pg_conflict= ' schemas > > and found that operations such CREATE EXTENSION, CREATE OPERATOR, > > CREATE COLLATION, CREATE TEXT SEARCH DICTIONARY on the schema > > pg_conflict. > > Is this expected? > > > > postgres=3D# CREATE EXTENSION hstore WITH SCHEMA pg_conflict; > > CREATE EXTENSION > > postgres=3D# CREATE EXTENSION pg_walinspect WITH SCHEMA pg_conflict; > > CREATE EXTENSION > > postgres=3D# CREATE COLLATION pg_conflict.mycollation (provider =3D > > libc,locale =3D 'C'); > > CREATE COLLATION > > postgres=3D# CREATE TEXT SEARCH DICTIONARY pg_conflict.simple_dict > > (TEMPLATE =3D pg_catalog.simple); > > CREATE TEXT SEARCH DICTIONARY > > postgres=3D# CREATE OPERATOR pg_conflict.=3D=3D=3D (LEFTARG =3D int, RI= GHTARG =3D > > int, PROCEDURE =3D int4eq); > > CREATE OPERATOR > > > > Also, when we create extension several objects are created in the schem= a: > > eg: > > extname | object > > ---------+-------------------------------------------------------------= ----------------------------------------------- > > hstore | type pg_conflict.hstore > > hstore | function pg_conflict.hstore_in(cstring) > > hstore | function pg_conflict.hstore_out(pg_conflict.hstore) > > hstore | function pg_conflict.hstore_recv(internal) > > hstore | function pg_conflict.hstore_send(pg_conflict.hstore) > > hstore | type pg_conflict.hstore[] > > hstore | function pg_conflict.hstore_version_diag(pg_conflict.hstore) > > . > > . > > > > So, should it be allowed? > > > > 2. When we try to DROP conflict log table we get an ERROR: > > postgres=3D# DROP TABLE pg_conflict.pg_conflict_log_16395; > > ERROR: permission denied: "pg_conflict_log_16395" is a system catalog > > > > But for other restricted operation such as UPDATE/INSERT we get the err= or as: > > postgres=3D# INSERT INTO pg_conflict.pg_conflict_log_16395 VALUES (1); > > ERROR: cannot modify or insert data into conflict log table > > "pg_conflict_log_16395" > > DETAIL: Conflict log tables are system-managed and only support > > cleanup via DELETE or TRUNCATE. > > > > I think for the DROP case we should throw a similar error. Thoughts? > > Please find the updated patch version (rebased on current HEAD), which > fixes all the open comments in 0001 and 0002. We are still working on > 0003 regarding handling conflict log table insertion errors. While attempting to log a conflict, a concurrent ALTER SUBSCRIPTION can change the conflict logging destination from all to log. In this scenario, the apply worker may already have cached the conflictlogdest information, including the OID of the current conflict log table. However, the concurrent ALTER SUBSCRIPTION drops the conflict log table as part of the destination change: +Relation +GetConflictLogDestAndTable(ConflictLogDest *log_dest) +{ + Oid conflictlogrelid; + + /* + * Convert the text log destination to the internal enum. MySubscription + * already contains the data from pg_subscription. + */ + *log_dest =3D GetConflictLogDest(MySubscription->conflictlogdest); + + /* Quick exit if a conflict log table was not requested. */ + if (!CONFLICTS_LOGGED_TO_TABLE(*log_dest)) + return NULL; + + conflictlogrelid =3D MySubscription->conflictlogrelid; + + Assert(OidIsValid(conflictlogrelid)); + + return table_open(conflictlogrelid, RowExclusiveLock); +} As a result, when the apply worker later attempts to open the cached conflict log table, table_open() fails because the relation has already been dropped. This causes the error handling path itself to fail before the conflict record can be written to either the conflict log table or the server log. In such cases, the conflict record is effectively lost and is not logged anywhere. For example: 2026-06-21 19:31:13.592 IST [263598] LOG: logical replication apply worker for subscription "sub1" has started 2026-06-21 19:32:26.731 IST [263598] ERROR: could not open relation with OID 16405 2026-06-21 19:32:26.731 IST [263598] CONTEXT: processing remote data for replication origin "pg_16404" during message type "INSERT" for replication target relation "public.t1" in transaction 698, finished at 0/017D39A0 2026-06-21 19:32:26.735 IST [263471] LOG: background worker "logical replication apply worker" (PID 263598) exited with exit code 1 Ideally, failure to access the conflict log table should not prevent the conflict from being reported in the server log. This issue is present with the v52 version. I have not yet checked if Amit's recent patch posted a few minutes ago at [1] handles this issue. Thoughts? [1] - https://www.postgresql.org/message-id/CAA4eK1JhZYRMP_YYa1j3uAK6L4v057= JDuM0%2BYLABOgAOYuwM8Q%40mail.gmail.com Regards, Vignesh