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 1wTpVt-000mPE-0g for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 23:24:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTpVr-00890i-0V for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 23:24:11 +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 1wTpVq-00890a-2Z for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 23:24:11 +0000 Received: from mail-lf1-x130.google.com ([2a00:1450:4864:20::130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTpVo-00000000YQg-2ajy for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 23:24:10 +0000 Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-5aa5ee1f07fso1560732e87.1 for ; Sun, 31 May 2026 16:24:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780269847; cv=none; d=google.com; s=arc-20240605; b=WOEgvJFvg0rqWly7K1WfHIVW4N2mYIhIR7A64T3xP77J25IRQY0n+HvHLyKB/mC476 MCZfecW8DkdWBXWmHFpJ08pN+1vbr0oM1veZLbMvQow4lm8n24Iq5Hb/dUdVYe3qgH9h wjd9CVspxiC3DWogvD7zVfMmQRie6dt0qUjQmCt2rT6oedenrvOCVfAt++sMS+DuKoNF hG+wr8GkI6YmIfyX2Jep/A7dAVRT4e5o5fAI3BkfxGzuM3eTtucIJKOPIfXXVMoCoLzO Amtyu2D3OJNmlLg9TAjsk35H75labvgVv6yV6MLwUY4/I9OR2zV66+ZgkVpXlY248rer An/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=oJcZk9EijFexwduYCpIKAeM64YWHjuU7KU+6t/D7ziM=; fh=5jA9hS0+y5lk9asAdLp0QftEIuXObYHJTTGjsPdQto8=; b=jof+RKJu412gw/4Bm2oAbFk4tSn+kIJ/8rFcpvfBMYDqEToXy+74cTdYAGpLfz2B1V IrVoy6warb78UVwvlaMry8a6nRQswuISX10Rvzm+TgYxkqc1de3VB9cA+GxAci1N1Pko TUXMubJZItLtC+rSPETh+lirWPTbeJY4QDbpiKh87KeBH5uFW1pS5TOrr+ASO6e55XIe ivgLj8myIEDARRm3rT6kI3DxwfdE20JW3AP/vNKEhF5tmeRPkT8X12Q6kA0lPchXaFoj RM5aHH3cMfwbcUUroE8fksNYxXQ7BhvLEC+6Y2aSVSOBxm0wRaxYKQnEt05fAGFEsvWn ngUg==; 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=1780269847; x=1780874647; 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=oJcZk9EijFexwduYCpIKAeM64YWHjuU7KU+6t/D7ziM=; b=tOQd8I92EWHtbE4w7LstwZ7th47+5osfjM8Rnh+4rJRAAa66y32D8x9qqLooxIys3f DiwPoklC2Ar7leO64DLOzz96XW0ax8HO21mRpz1f4bmuHsP+m+oVCUh2rOv+MvRIscaK XPn+UMc9BTC2YrruUXYV1j1o3WR013Pkmw8Rjv7jZkkwadipzZvjKB/4Jh2lKX/C380G gkO3srclBTL4red7GQV+xXpvihTcx1gBtYMo/2KrGkh6Pzi3/L0jg9ilANj8MFKDfFUU 0fuv6fo92ejWF72AOnYA4ZRCsPOX2RvGFnR9Fr36uUm3aMhgTWtbaOpchFjBPCS8p9MQ vDQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780269847; x=1780874647; 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=oJcZk9EijFexwduYCpIKAeM64YWHjuU7KU+6t/D7ziM=; b=KNSMK0X+6kjguaWXR3DA+7FyuHTg7kRss3jR0Rdk+W6+VWx3OHOoFG7teFTTO2PXzf azrmNRnfHnj/xJ2OD7TbguSz7j325eXZsDrSf1YZcFiiaYe37qyf+/u9oejfX/QtYBnP AI9Ajh3nRCoMo2Qn8Jb6SD1VBRbZc3CfZtSYTs8NKd9heW3dIiXIB/hKAmXh12lbAdYa f3yKiujb8emnJxWORNKVLcUQi+UpVeV8CB9ux6wJZZI7eyMm3ngrqAopIkXD/dzpnR7w nT954RjOBS+v/xOq1gAuenrUYnKQvw4X3U7PslOaM41sSAE1SOxdUgkr2K+6hO0NaBT9 JMaw== X-Forwarded-Encrypted: i=1; AFNElJ9yFKWWJIzcdZ+hH3Zzn62RzoHCUwNAMRsTnsFy/DpVGdgtXgkSd98QCM79+sPdLHTeXP6PGsZGt8ZELfNV@lists.postgresql.org X-Gm-Message-State: AOJu0YxYRzB6GKd7otRU5HS1liHp7E61rrL7LF0p+7jFfVLFqMCf3a/S UJY7YFEo81rMcsy3GXCc3xQmKIbiNSQrlgQfAxmoMotKY9KeqZv3lUL6cYtrQF4EitdNBJUukTT i5gbCVB/D1MrLkUN/j3Vt7kUlPngAmps= X-Gm-Gg: Acq92OELwQCQ5n4KZa5FAslD+YU7pJdhxmUuNP8pkG+oFCTLOsf3C/gS4WIPUm7qzdO JFpySgtulWJ3uqgpCQb8n+04Cc7vZCpv3TziwagIZ0vQKL7RXpllT+zQzQcAA+pjXXEfB/Li3Mh 2LEFivtz+KyQQ9aOSeiN0EIvbBAxSuSO+qs+S/WHB4zrhp9ydNZssuuRkcXkmx4YSa/j5/mUTZd C+ngDaBX9TKgQCmaCRd0Skv2f89r2gtwQ3IvjfSMgpPdZ1OP3LQ33K7Ugg6A2wD+In4MamPfaya BXc4NoFaOCU2PsI7qDG8b9MCpqqiB0JS9gsdoag4KCgCNNbiJBgdxUe1uBlM X-Received: by 2002:a05:6512:66db:10b0:5a7:49ed:18a5 with SMTP id 2adb3069b0e04-5aa608fc2eamr1597601e87.31.1780269847213; Sun, 31 May 2026 16:24:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Mon, 1 Jun 2026 04:53:47 +0530 X-Gm-Features: AVHnY4JIrRXXjeCQJT2elOstGuAWJZiNY_rJA_iPEowThQG7Jk9HkbCmG6dQ7aw Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: vignesh C Cc: Amit Kapila , shveta malik , Nisha Moond , Peter Smith , 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 Mon, Jun 1, 2026 at 4:36=E2=80=AFAM Dilip Kumar = wrote: > > On Sun, May 31, 2026 at 5:38=E2=80=AFPM vignesh C w= rote: > > > > On Sun, 31 May 2026 at 11:43, Dilip Kumar wrote= : > > > > > > On Thu, May 28, 2026 at 2:57=E2=80=AFAM Amit Kapila wrote: > > > > > > > > On Wed, May 27, 2026 at 1:34=E2=80=AFAM vignesh C wrote: > > > > > > > > > > On Tue, 26 May 2026 at 15:08, shveta malik wrote: > > > > > > > > > > > > On Mon, May 25, 2026 at 10:13=E2=80=AFAM vignesh C wrote: > > > > > > > > > > > > > > > > > > > > > Thanks for the comments, the attached v39 version patch has t= he > > > > > > > changes for the same. > > > > > > > > > > > > > > > > > > > I have not yet looked at v40, but please find a few ocmments on > > > > > > v39-0001 and 0002 merged together. > > > > > > 4) > > > > > > Do we need to have CommandCounterIncrement() after > > > > > > heap_create_with_catalog() in create_conflict_log_table()? I th= ink > > > > > > even if we are not doing any table_open etc for CLT in same > > > > > > transaction, we should call CommandCounterIncrement() (to be > > > > > > consistent with other such calls of heap_create_with_catalog an= d to > > > > > > make it future proof). Thoughts? > > > > > > > > > > I felt this is not required as we are not doing a table open on t= he > > > > > newly created table. > > > > > > > > > > > > > Okay, command counter increment would be required here if we furthe= r > > > > access that relation in the same command. I think I am facing a > > > > related problem w.r.t newly created subscription. After applying fi= rst > > > > six patches, the create subscription fails as follows: > > > > postgres=3D# create subscription sub1 connection 'dbname=3Dpostgres= ' > > > > publication pub1 with (conflict_log_destination=3D'all'); > > > > ERROR: dependent subscription was concurrently dropped > > > > > > > > I debugged and found that we get the above ERROR when we are trying= to > > > > find the subscription which is not yet created. In this case, it se= ems > > > > to be happening because we are using a subscription that is yet not > > > > created for dependency recording. This raises a question as to why = are > > > > we creating the conflict_log_table before subscription, at least th= is > > > > needs some comments. > > > > > > > > * > > > > + if (mask & (ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE |= ACL_USAGE)) > > > > + { > > > > + if (IsConflictLogTableClass(classForm)) > > > > + { > > > > + /* > > > > + * For conflict log tables, allow non-superusers to perform > > > > + * DELETE and TRUNCATE for cleanup and maintenance. Also allow > > > > + * INSERT and UPDATE to pass ACL checks so that later checks > > > > + * can raise the dedicated "cannot modify or insert data into > > > > + * conflict log table" error instead of a generic permission > > > > + * denied error. Still restrict USAGE for non-superusers. > > > > + */ > > > > + mask &=3D ~(ACL_USAGE); > > > > > > > > I see the point of giving a specific error instead of a generic err= or > > > > but this functionality is used by pg_class_aclmask() which is an > > > > exposed function. If we go with your proposed change, isn't there a > > > > risk that some extension or outside core-code using pg_class_aclmas= k() > > > > won't invoke that later functionality (CheckValidResultRel())? If w= e > > > > decide to go this way then we can change this comment as proposed i= n > > > > the attached? > > > > > > I do not understand this change; my original patch 0001 has like this= , > > > that mean we are only allowing ACL_TRUNCATE and ACL_DELETE for > > > conflict log table, whats the reason for changing the same in 0002? > > > > > > if ((mask & (ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE | > > > ACL_USAGE)) && > > > - IsSystemClass(table_oid, classForm) && > > > - classForm->relkind !=3D RELKIND_VIEW && > > > + IsConflictClass(classForm) && > > > !superuser_arg(roleid)) > > > - mask &=3D ~(ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE | A= CL_USAGE); > > > + mask &=3D ~(ACL_INSERT | ACL_UPDATE | ACL_USAGE); > > > + else if ((mask & (ACL_INSERT | ACL_UPDATE | ACL_DELETE | > > > ACL_TRUNCATE | ACL_USAGE)) && > > > + IsSystemClass(table_oid, classForm) && > > > + classForm->relkind !=3D RELKIND_VIEW && > > > + !superuser_arg(roleid)) > > > + mask &=3D ~(ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE | A= CL_USAGE); > > > > This was done to fix Shveta's comments from [1] to throw "cannot > > modify or insert data into conflict log table" instead of a generic > > permission denied error for the owner of the conflict log table. > > [1] - https://www.postgresql.org/message-id/CAJpy0uANkzTyUjO2W0=3DRtaJC= Gg=3DVYcwLGGCpqax=3DzKJgNbB0Hw@mail.gmail.com > > Thanks for pointing it, I will analyze this behavior and give my opinion. While thinking more about this, wouldn't the behaviour is same as pg_toast table, I mean, the superuser will get "cannot change TOAST relation "pg_toast_16404" whereas the owner of the toast will get a permission denied error? --=20 Regards, Dilip Kumar Google