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 1wa5nE-001Wb2-3A for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 06:00:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wa5nD-009pXH-1h for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jun 2026 05:59:59 +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 1wa5nD-009pX9-0a for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 05:59:59 +0000 Received: from mail-oa1-x2e.google.com ([2001:4860:4864:20::2e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wa5nA-000000012iw-2j2a for pgsql-hackers@lists.postgresql.org; Thu, 18 Jun 2026 05:59:58 +0000 Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-44273dcaca8so1387066fac.1 for ; Wed, 17 Jun 2026 22:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781762394; cv=none; d=google.com; s=arc-20240605; b=Mszi1VP4AMX33bdNVFL4WalmYeB6+wDOg9D0yR/tP4fC94ZH2lTh/pQDThooV1ajFo 2jIKcD7A/LZLp7RrOizs+eGkm3oK6PR2mjCVC0ZWNMrh5J+VQhuGOTgacEY+qOhGR0Qj q+Spj+deguuS5SVifmDLLHvieVHbV18ZquZ7YcI+FynrOQe6IamcPCyrsAk2qV7Zo1DR hvqHN5xFDOinderhwwxTQ4VNnjLnH4U2N8dyOrCGUnv8p4wcn1nvF+S66ioboHVLUZWI 3XzEwAvZ24+CZR6SjsIgl56yvwI7/EY4GahAumjuTuijn6BflPJp+H1xzTWPQ7V109jH ntew== 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=C2oiFggFVhRzrUP6/HblTOaoYSs1qv9XldMQTq7Yy5A=; fh=28sDilGUv484AmzhWkYZgv/0cg1HQFW60ZchAyOBv2Q=; b=etMbXyO0Qe3QUjoETITzDixYLXI6z0R+k0r3kZOIoTNBVDsZqTFiRD3ygESBpYhwHw mWAIaRIoiA9GG1YGElRmzqkTM/VoqWJKUAyObVB6kPgF2/npZb5GFm1v3RoQjcehVD78 SJMtcqp/B8EtBikZoKjoebT0dWzuLZe8W+JK7LkBrtYoWz61bRzrFhX5MRA31GR0CZ58 hewXE6/kBTROewn5YGJ8689hBAog5TSir+4t4LXc/sPWmOBQ1kqs/MpVi8NeT5aqZYi9 SrKJj/NmCfCFaz5Z/+cX5vn6t+vjuZP8TNow1bEuDs33/ETJCJQPNAxjkRvwKFhgZSjr U//w==; 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=1781762394; x=1782367194; 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=C2oiFggFVhRzrUP6/HblTOaoYSs1qv9XldMQTq7Yy5A=; b=Ob80MTG8Ou/nEOVqi6AQcFCbCmo0TMaqi8SuFYGHcm4KEGT+3YtzS84GfgVY1HvC0+ 3UOXQtJZ/hGv+daSCtUeizJPvnqj5R/dEaakzXwB7jjBqlnsP2dbaX8qxZs69bkxNgwk xhtam0TnbGYozklj/ufZSbWHiQZS+N+siX/nWlv0n8fB6zN1ZKUkibkT8KQSAmJLkEId PCcYR/jZMpamZAn2bRxlTA+9agJ3naMTGRYMK8QGoYwsX004uUEJxLWqG7Q2oZPiSm/4 cAcSGepklJwEjf93XjN/xkBGRZYLVxhJ1bncQCVsgc/G46kVYQrprRBE7KuboWbTsnbR uskg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781762394; x=1782367194; 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=C2oiFggFVhRzrUP6/HblTOaoYSs1qv9XldMQTq7Yy5A=; b=T56ndAMlvplRXPMhPy58uT7jwOUFGtT83UdoGFanuoM3C297DBZrWo+H6Fh6QDSYoY zAgI6gUJ1uwjSrlb7yRXjazI2Tj8ZBXmtVVM5kapnBVYtys21Zw70/7VwoR3ZxPCGEG7 55qZoq66GLqC5c+GsimfKV/hYw8ZGsbibSNmnk6oWVz8IiudwVmoPPApk+10g5TSg6KJ nXuIup9YcNi7hbU2I36wGimR6ZR2D3rtEZ/PHwPLq2CL3/DSTvArnNTrwhwSivTryBfb g5ZO7hEFfKxAWGrj8CvXvl/F8J1j4AE19WJxsgzoRNQ8/49r+U/RKek8OhCH5XKeNL/g sv6Q== X-Forwarded-Encrypted: i=1; AFNElJ9pbJac5NizZQy7roKqjWwIlPKyCawYng+Vme6VjicEC6SKzL2Fo12W39GzHbjDzwKX6TxlKLVJZtPQ6Tdo@lists.postgresql.org X-Gm-Message-State: AOJu0YxE2Hfd5i8FHwnr1jhPspZRdVfDKM7OT7N067KmszqTe8DB5cbU rIV9l9x2Hzfppq/uq+X1fulQ4TSCtkknypslGbkkIO8QV2UbIeTRYcnXycVYp4xQm40DvEqjUUI L9BZKSw+wOOhpBOIOfbZpEOU0Oi+xOew= X-Gm-Gg: AfdE7cmOnXzIwA0C7Crjrq38+CEgUVQogRW6yod2G10rGICC84WrJcxVFFnlKHbMzYJ 7sg361L5D5iSHvCQbjI8m6GtpRwhwmEqpjOL4Cc1Af6v6My7K/j/iUxxSKrnNbjHzclGerA085H qxWHNqFMzvJpR6F20z6J1WWOGwPWfBlvvNFQWkPKF3I+3/kCbHho7P51Piaq+27XF6hk9P19iDS +XuzL40o1Uq+/FRupkv+tOzZvfGiIJ6DrikmXtpvbX1X/V1K5/cwPG1RBDCsadEXJrpQrufabM= X-Received: by 2002:a05:6871:ea12:b0:43b:8993:87e1 with SMTP id 586e51a60fabf-446dd622137mr1704525fac.14.1781762393906; Wed, 17 Jun 2026 22:59:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shlok Kyal Date: Thu, 18 Jun 2026 11:29:40 +0530 X-Gm-Features: AVVi8CdmHqD0im-zTBQmz-s4utDOz7jg0YfNeUZXFNHNJKdGGacA0c-y9qWTp4E Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Peter Smith , Dilip Kumar , 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 Wed, 17 Jun 2026 at 18:31, vignesh C wrote: > > On Tue, 16 Jun 2026 at 05:19, Peter Smith wrote: > > > > On Mon, Jun 8, 2026 at 9:39=E2=80=AFPM vignesh C = wrote: > > > > > > On Fri, 5 Jun 2026 at 07:59, Peter Smith wrot= e: > > > > > > > > Hi Vignesh. > > > > > > > > Some review comments for the patch v45-0004. > > > > > > > > 4c. > > > > IMO there should be a separate function for handling the subscripti= on > > > > footer/s, same as there is already a function > > > > addFooterToPublicationDesc. > > > > > > It is not required in this case as we don't have multiple footers fro= m > > > 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 easier = to read > > B) The 'describeSubscriptions' function is too long. This would make > > 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 ensure > > the appropriate 190000's get replaced by 200000 as soon as the version > > number is bumped. Better to flag/comment all those places now, so that > > nothing gets missed later. > > > > (A similar review comment probably applies also to the pg_dump changes > > 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-huWB= Zoy%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' sc= hemas 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, RIGHTA= RG =3D int, PROCEDURE =3D int4eq); CREATE OPERATOR Also, when we create extension several objects are created in the schema: 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 error a= s: 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? Thanks, Shlok Kyal