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 1wTZQH-000c8y-2E for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 06:13:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wTZQF-006xVe-2i for pgsql-hackers@arkaria.postgresql.org; Sun, 31 May 2026 06:13:20 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wTZQF-006xVV-0y for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 06:13:19 +0000 Received: from mail-lf1-x12b.google.com ([2a00:1450:4864:20::12b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wTZQD-00000000NSI-0D48 for pgsql-hackers@lists.postgresql.org; Sun, 31 May 2026 06:13:18 +0000 Received: by mail-lf1-x12b.google.com with SMTP id 2adb3069b0e04-5aa619653e4so1027488e87.1 for ; Sat, 30 May 2026 23:13:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1780207994; cv=none; d=google.com; s=arc-20240605; b=fNpoEGD/WfP2ZTrOlBcLzBTqgPqyfsv3lnp42IfLLV5cGsriXDrmX9BjNh6Ja8zWqF tPdT4Ju5d7VYEQFWWra0j7iGGFv/rcl49HBXvQI1+9f05l69mlWboEt2G/CXPa3pVrQ4 3yJASfBIAA4sdawCAsWyOfDFq7LadY49xQjCfg3kqWx1r7mSQZCjMbau81UfdqIs5cW7 1agvTlql1+yzKq3uHkRXimh/lDWTDPZqVdygk0yDrOL2+6Sp9OLaxB3nGJCwpOnT/F2k E5KFA/YdquNATb/qateQJ4J74K3L1RCAf3iwT9F0F3P32QTGKvy11mQ4LPo0n4IaPxDM W1OA== 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=5w6FiU9EA9LklkNK22yB4S5rNyn795RYLtNXe+kg+KM=; fh=tUCSouXRWRR2bW8/uA6aUzTbPZHC5PIiaWaTeREj4Po=; b=K8qlDwyMKzNW+KYBmo6+COEoRsZJWUofW9D/fmxrMLcAG0ToCT3pHiKPNwpje/7Cbu /izXzJJ0TBW4GY5kZBBNxDWwn7f93Q/mU+kiKwNyctZtc3oeF4MPJez3yb0wKH28YZ+d /I8FrCMG03UNh2euZFMaJ4NXeDKIhsJZ1FeIb1hGj7Rz4kth9vhYp7hiXLUxdc1wV7Vu rvfLcd7yasUaMmK1cAc9ybtFogbXvVtaBhSg0CGXuMyPO5DXU67VjZL/JhTtdAD4E0Kc BC/NYld6oy6Rrsfb7BvpQ4zY9FpkSXuinbBIWREknKN6at7oirWW4cfmqtqMo59LWdgA l2VQ==; 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=1780207994; x=1780812794; 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=5w6FiU9EA9LklkNK22yB4S5rNyn795RYLtNXe+kg+KM=; b=MsBAbdoRnoUa5+LiYkjFrCL+WFPO05C0MWwz4/qfoL4ktv4xX9bZ4Kv5ayb66Cs3mV EOKG5ssRu5+ggnLhullfNNZicYe4DAaGolpnxJHh+JZdVNvNjihdkO85yKiokHVp8Umk zS7HyPbC/+SqxW2u6PyI1KqptPGTNjTOHnQEec5BzBoKr1DzxRim3j/ZBt/1muvyPxcl SQJMYNO5/zUN1zc2sEyGZX2nJV1xrweMYI3NrcyDyH1A29izab6SrFrIacJ800qNbVZ+ 90/9YnMOv3a4X3pFlsqC5rPI7gKvy5mtcJbSACE/ay0xTGyR4MrO+v6oDxjCTEV8i1IW koVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780207994; x=1780812794; 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=5w6FiU9EA9LklkNK22yB4S5rNyn795RYLtNXe+kg+KM=; b=I6dl9u5CmXQ+mgTT5jtLz4bsxd6sBmTgCS98y3gB7mf0QPU6p6/ddhLl+4XwHn5oGw xzhyPUMZMV5fNjRcOMa6QcTJgU6itQ3Hm26TCDUqp4usdaoIhnl2n4kMimz2dT5qJ+sO jZtlqLHodyV9Qiwp2hx1yuOvoh/39yTENt1uXtE/DwKh2GPlypnhAKFeSKBMHh0vggaZ fgHPTPc8LYXTrW7bPjW6Lttp0tOTqmKbnX4ADq9XPwDY6/+XVVCglYpuFEL5hksm8iha 3hee/D6bZm9F+spB5qq55CsYXBvfiupWmd3gziALbXzrKoEPdR0Nz1Og4v6+YaH42MSX zHZg== X-Forwarded-Encrypted: i=1; AFNElJ8YUYTpSUX4UTRIzCgC1c3AmVlntnbS8NHgSKthEAA9o/5chJ2xem2cdfjvnaFnPlDNveYI3JagpM2fi0Xe@lists.postgresql.org X-Gm-Message-State: AOJu0YxxXGWiG8P6BuZrAZOcDVIcg2kKZSAh+RDGwDd5lP9p/rxLJWTD RLmeMuq56wUbiCm1VxvIz6nA4n0LVLqrdPxi94+E3gQ2tb+Z94ixGAKF8YAGOJZbRT/K5HAK20z yPvZMKF4f0L6MA8YDj1tcPed/bO6rnKU= X-Gm-Gg: Acq92OHPJbFnhyW6DNBaU2bYmRJOMazOGocH58+j3moEgaaAzgdYmDNp2vSuND0rjpc IVyNuOs4+HOpg/6tvBnmCkeighCxleJZxApc0J405ej1zOYDpB5pXwAawM7QkDhIWZ6O5Q7sQ8g oTghWzjDjJijlLQNiS3oKgwnrZ1MTR6hwf4/pAlikNHEzWj7/jeHhlykEV7pzICFmBkCO1oNod+ SrU9nLcaHXR0DO1i3uSO0y8JLwLvdcu5SQt3wz1WDzffx78aqM6MSaKahSMf1q12YLs43apk1J9 wWNfP6Ld/ZzzWIeJCzQ= X-Received: by 2002:a05:6512:159b:b0:5aa:6b0b:1f30 with SMTP id 2adb3069b0e04-5aa6b0b20fdmr114725e87.1.1780207994364; Sat, 30 May 2026 23:13:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Sun, 31 May 2026 11:42:54 +0530 X-Gm-Features: AVHnY4I9F7K6vk5S3QkfNjRjQms66zrc4r6qF9SjbMF0kJfhHc-ghUQir_E4Tdw Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Amit Kapila Cc: vignesh C , 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 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 w= rote: > > > > On Tue, 26 May 2026 at 15:08, shveta malik wro= te: > > > > > > 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 further > 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=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 seems > 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 this > needs some comments. > > * > + if (mask & (ACL_INSERT | ACL_UPDATE | ACL_DELETE | ACL_TRUNCATE | ACL_U= SAGE)) > + { > + 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 error > 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_aclmask() > 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 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 | ACL_USA= GE); + 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_USA= GE); --=20 Regards, Dilip Kumar Google