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 1wV19P-001cW9-0H for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 06:01:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wV19N-0057D0-3C for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Jun 2026 06:01:54 +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 1wV19N-0057Cs-22 for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 06:01:53 +0000 Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wV19L-00000001Bcj-1BF8 for pgsql-hackers@lists.postgresql.org; Thu, 04 Jun 2026 06:01:53 +0000 Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-2c0c35980fdso3334225ad.2 for ; Wed, 03 Jun 2026 23:01:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780552909; cv=none; d=google.com; s=arc-20240605; b=MYh9NhIfqQ2dq59JCZsdaqyKoDc0Wezkwlb8uXVnobnEzFm2HRtSBEVD21IlMIosIk oCMQjZKaeBJQvp+7+mA6i0M4ORVU8pkDgnUEvo5wu1H8q+BN7HJV24Mz+AGNWaMaFJnB AkOx0aAB/na5PW9kdDaGxrhNlxLMdJwXaVAeGewOz8EH7PmUVRGqofXr/Hi664ABJQxO kqTjNV+1yG61cXXeHFOZjYeYSQMhBLHDLnxbyeANhMXBOG2NiZUjslcJlv/VDipT5Rf6 YgLkV00IWS/KlN2wOe7r1wmQpub8oTFPWFCjJTgMinhZrcCU3wD5nlT4zcnD1WzC3vy+ SnWA== 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=wx4ddu1mLBTxrv6Ohfsr46HSS873v2UarVMrNRAij7I=; fh=eCgBYWfcZSvHGXDuNXbGcKIYqfhpAxxSywpvAXWr/fI=; b=lFYtMJ5LiTQiyZZiDyGPw/o08ShQ+hOOMABmF+0Kah2H8XOiV35zCROHHoG1DVvuFK 3xOHefsKSm3+EA9d3yih9NsMy7hnZBjaB4gLTOirL2fvsSn+N1Y5RUQh8nVzhHU23YoN oSOt6TjdELiofrgLYqArMSs4eeqatfRpg00kjh0CHTFwB4S841N0O2fZAp5chQzOk3E0 ZNIp71ix8KlBg/DXM38nxBeUVK+yoh3EHbToCS/YXutGxNAUFBiCKa1hcmirJOsSBilR 5/F+AgSSgiOxc56gSQ17L8CoRcWHpqQVOIqhNAt/xIunM4nVJMpm/es/5gvaneQDZXuF Orzg==; 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=1780552909; x=1781157709; 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=wx4ddu1mLBTxrv6Ohfsr46HSS873v2UarVMrNRAij7I=; b=mUHmUna9upgDlIguAdlxv0blor8bGtMq+TToObFzVgnmdooKotgd5o/1L1HN1KMPos y8E47SKJ+8MENHLbGuBTOuLF2FiTHXtBdilIpOJJ37XFzBFIgjz/MSdGAFzdBQXxNRrG Ugmx0bkl+/aUHloEM0uOj3KilUzDBkhPfeokDNBh3zX6IaRB5WfUNIi3NxKDZ1xlBNBX 2BH9q3jU5BRiWhiVHWrDfMdEujDLkDaDqvL8iUSqeU7GskTslz162hGFtHxElyzvWLMJ +loLlouVwJxR1rp8FoxlsZVyogvgh1p03mzGMttWYKkadwytwcVa8OHX1Ipt0/WxLyyS 1a6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780552909; x=1781157709; 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=wx4ddu1mLBTxrv6Ohfsr46HSS873v2UarVMrNRAij7I=; b=VhW2KGUkG918tQU4p6G/VNbPPv+YUn69SyUTWMeibzA7wYM/Q3vsTrQ1rhOqxyQyBq 24WCHScm0W19AoeIytvlNuJ58j2JoOHozMbZxoZV8j0QUW03GYKPlD+sdpMPsW6R6LH9 hC04n8FsqjihUb/dehN53WnIz/ozT/CzZZRHPFgR97hfGDk01zkBBsVZotf86vkIs5M2 uVVgvjWKITBbilVgaBJYRJmeqnipsADnPwgscsbRw5sdhHnvHTR1HYVWuDkhoT5UpRYx /6dR+rfLVWEPkkOW2icJ6nKrZa6zDd3OIrCCUUXebzKKY4ziDVzkzVHO2Fxtvp+lAFHx G1iw== X-Forwarded-Encrypted: i=1; AFNElJ/+LjS91j7r8dQC3HiL/RDkMJhX8DwMH8gDR59q5oJxu5gsWqTf7PhmUHA48MBvrjtPrjN5HWbKD5vI376j@lists.postgresql.org X-Gm-Message-State: AOJu0YwF+pwqN9ittXinXv1cXyrd6scCY8wpz21lCctIRGKKhBrdCG9+ yRdGR+Bwj0e66Ofmay+UaNEqeRe27flYRQFI0bReFqmq/CzCzCLkP/XmA7UR/4CxT480QCNNRSA ZedjwTPvWvvXwbVBo5AzNZ452qtzPobE= X-Gm-Gg: Acq92OHZIJoJ/XlAohXQNpADN7NwDPjCWwB1wrtOqKz98v022NOHBZa5dkbWoM2sCrN hZeirF7ASlCNPbWCn8m9LRP6g8jz0LqctM3hxp3GVCNOtoLyFiHkFJokUFY5BN0ndIi+2I38hws 4Q0sBtb1eNrcDCYYNpGN3KVw1FKSp4stWc+b6dwBCeApmQVJajm/aV4VakB3hxP8JP0DE4yDhZh skGvIbYotE4umMuNb4ywNeLgdnwjIUm/h92tQ8CuMbm87T7CHJG8BERKZevGfHfx4LyBX2dcKAu xzijVnd68GzzQKWdKq6XrPef6yILPymprAi5r8RRc9bg77v8AwUPlKiGS9gZv7kpSU0U22PHEAd WZYHCJxHpQpgLsN4nKYo= X-Received: by 2002:a17:903:1a44:b0:2c1:98b7:ecf3 with SMTP id d9443c01a7336-2c198b7ed5cmr24765825ad.23.1780552909050; Wed, 03 Jun 2026 23:01:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 4 Jun 2026 11:31:36 +0530 X-Gm-Features: AVHnY4LtCpOcA5kUMVR7MxpQY7iNGzn75nzP6nStWJQvzcoCeg9c6MfnyHaG1A0 Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: vignesh C , Amit Kapila , 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:54=E2=80=AFAM Dilip Kumar = wrote: > > 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 = wrote: > > > > > > On Sun, 31 May 2026 at 11:43, Dilip Kumar wro= te: > > > > > > > > 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= the > > > > > > > > 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 = think > > > > > > > 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 = and to > > > > > > > make it future proof). Thoughts? > > > > > > > > > > > > I felt this is not required as we are not doing a table open on= the > > > > > > newly created table. > > > > > > > > > > > > > > > > Okay, command counter increment would be required here if we furt= her > > > > > access that relation in the same command. I think I am facing a > > > > > related problem w.r.t newly created subscription. After applying = first > > > > > six patches, the create subscription fails as follows: > > > > > postgres=3D# create subscription sub1 connection 'dbname=3Dpostgr= es' > > > > > 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 tryi= ng to > > > > > find the subscription which is not yet created. In this case, it = seems > > > > > to be happening because we are using a subscription that is yet n= ot > > > > > created for dependency recording. This raises a question as to wh= y are > > > > > we creating the conflict_log_table before subscription, at least = this > > > > > 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 e= rror > > > > > 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_aclm= ask() > > > > > won't invoke that later functionality (CheckValidResultRel())? If= we > > > > > decide to go this way then we can change this comment as proposed= in > > > > > the attached? > > > > > > > > I do not understand this change; my original patch 0001 has like th= is, > > > > 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 |= ACL_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 |= ACL_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=3DRta= JCGg=3DVYcwLGGCpqax=3DzKJgNbB0Hw@mail.gmail.com > > > > Thanks for pointing it, I will analyze this behavior and give my opinio= n. > > 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? > Okay, we can have the same behaviour as the Toast table here. I had asked others' opinions on that, but I did not notice it was already fixed without any feedback or comments. thanks Shveta