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 1wZ0ms-000hZ2-2h for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 06:27:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wZ0mr-00ABVl-22 for pgsql-hackers@arkaria.postgresql.org; Mon, 15 Jun 2026 06:27:09 +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 1wZ0mr-00ABVd-0L for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 06:27:09 +0000 Received: from mail-yx1-xb135.google.com ([2607:f8b0:4864:20::b135]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wZ0mp-00000000Qxh-30I4 for pgsql-hackers@lists.postgresql.org; Mon, 15 Jun 2026 06:27:08 +0000 Received: by mail-yx1-xb135.google.com with SMTP id 956f58d0204a3-660633a60caso465272d50.2 for ; Sun, 14 Jun 2026 23:27:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1781504826; cv=none; d=google.com; s=arc-20240605; b=b0fGh2jwA1E4lf8+9pD9c3zrrs75OXFn+h5jbsM7f8vfeng5Xzcx5w8XMFc/CU7XpX ZYTeSj8SRQ4SxYIHM2WD2XRehESRVzZmtsRa7dw8Et+uAFvqstm5DblIToKtbkJ2MZVY Zd+9CiIwezglhHfgDd1ykH3FE+LtzTP5jpu2kPfjUk8uIofWU/Z8aMZbYEHgTXt/SssH UuUPhJAW3iRUgSwtGQvp6HVC0S19f6hF+z1l4OCtTUChPYDveDgGdE06HIEReglpspE/ ECyZyC4ohbsgkoTFF9659zC7s50Clq3cZeUYn9QR2XreeNi40drZzv8AZPt7xSChXsx9 QISw== 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=fe1zgZYV3+AZVuRwqfBtgIIj2o31Eryj6dx17YDzeAc=; fh=cZKJAeZ7OojoNLS77Z9z2fKgBEp3TKDc5PuZgxUYTbI=; b=F7SvIXHR3li6l80Rihi9X5Io17NXA1Ug1il7ts5NpPS7U//+mQRMvj5Q9+edpCyKqJ eVPgiEq+6LdzQ2BIEcmLZOxPlW6oQjqrFkN7XtOUs0YEAuLFT2rXYgC7uwi7CfCIAmTL 9fgZaRlIU3ssXb3uSrmVE8ywVTrMEBVWFw7Tm96lwNFXSZy1Afk2VDqO/gQdNA2xjN6i y/TMUBcgDIRloq2OecqFqPOgNqg79bLiKI1zL7zy0Sk03/pqtqpOce73yReTDvHEKAPe 55BlloxLYNt+zkR7JDV7RxJ9zAfce2fqcVeSUHP5dT5fYlcIyx1Lmpd5sn3NptVfslIe rvDg==; 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=1781504826; x=1782109626; 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=fe1zgZYV3+AZVuRwqfBtgIIj2o31Eryj6dx17YDzeAc=; b=RnMzcbSWKZrJ8V/HGd7LAmbOndaNJGCHFYAQT3RRhNG/zh0wWgptGcR9RHIV2meism PbVwRcXt4zWsMaIHuhjQgz2HMhVynatUcJCHksg6HOhodKFMyJZNGaarppB7wtD18/AT G56Wuoc/nxnD4DVsf9Ky8qJunEOH/iugZRomyEAkWMcVimGi/N1+8xsqKPCEC5/s8n2W JI5berMJVF1HTmALz6ZLxlY3xMgsaQ5famnd+J8o8oNWjvhfdWquq38IMEL5K9xC1mfA uuYR0/az3Ex10OmeIcYRY+qM9bxH/TzElxs1PKuTWGNDX6IDtQCPWFkiFbxQkUeF+MQ5 f/vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781504826; x=1782109626; 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=fe1zgZYV3+AZVuRwqfBtgIIj2o31Eryj6dx17YDzeAc=; b=hv5W9e2/b7ugLPR5bmFXXPuYqqE1LW2uSmLuvdTck6Ddd2UW2+kNg7URipzczNHEfW +7f6jJgrKLjH0tpMnJniZOYvAtalGbloCKdahlwMr5mZFp+PACXF6qpD6I6lxFvcZWQ/ Krih3rsQ6s+rs82NjyTOTEePoBLdjDJRhDdzph9M5cpAB8Oc5QHNDNMK5G3q1BLn5TY3 jDc1OGSF8Uq+M+wPYb8fq68Up0Khv6orwJxtzjVy7HoKaDRUKySwS1mzarriB8aHKUNQ dSdVZCExw2YLkqHUM5ckhmhtcL5Qv4eVJq8RUDToxAG7jK6BxKVJ4wc7WTZehaF1sBp8 4N0A== X-Forwarded-Encrypted: i=1; AFNElJ86Czc4/kd/QZVci1YEQmFdqD7F7c+1at2O9kRFLk+ZaAjJ/U+V4PbvjeXg+KX/Rodur5VMtXzJXPrZyF4L@lists.postgresql.org X-Gm-Message-State: AOJu0Yw1CE/vTAUIKyODBgMHC0pK2uPbW++VT5vDj2X+bPVR92d723OQ 0V44uJljae3IrmWkEOX37tT38PvuYhaklw/Iv14WuRfNdYlZwtNvuimjqHFODTmff8f6GshGIiS T223V+Fk5YBm9CoLVNa5SbV3H6VpTKeo= X-Gm-Gg: Acq92OFz1jLzxVWQiniQHD8LyzzVGVLascgS/c2HH/oj+uwh9geFR2FNTCE/PuWxXAs ujJJmprsJeAQvDFVqNgto52bBwpkVgNJfYxGmlR6sfLoNlRPnbF3lly1Jc/V+dt51DcgVw9Ehjp vpJj/qNRPVvnz/RJoE2A1/3whbvKwcTKPo0oKSCqAfFMtT55MWafV7Pb0zy8MogxS9TgCnkCh6p mBAunlgI7jqkTPSN0rV4XpMPDdF15dYJLDvI/QJ2ZHHIWF8ONO45WEVusDmMktoWsFQWZbIyUUC PnjTis/MWQ== X-Received: by 2002:a05:690c:3688:b0:7e1:e20c:1e3e with SMTP id 00721157ae682-7f8c45cab57mr100753227b3.28.1781504826565; Sun, 14 Jun 2026 23:27:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: vignesh C Date: Mon, 15 Jun 2026 11:56:53 +0530 X-Gm-Features: AVVi8Cc2J2nIr1TH7-1NlcWqscKl-cTVRXWeiWOzRCYtoo2LcYvYnZhBTnbWZgE Message-ID: Subject: Re: Proposal: Conflict log history table for Logical Replication To: Dilip Kumar Cc: shveta malik , Amit Kapila , Nisha Moond , Peter Smith , Masahiko Sawada , Bharath Rupireddy , PostgreSQL Hackers 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 Sat, 13 Jun 2026 at 15:46, Dilip Kumar wrote: > > On Thu, Jun 11, 2026 at 5:53=E2=80=AFPM vignesh C w= rote: > > > > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar wrote= : > > > > > > Please find the rebased patch > > > 1. It includes the new 0005 patch for reporting errors for DDLs on cl= t. > > > > > > Open comments: > > > 1. Recent comments from Nisha and Shveta after v47 are still open > > > 2. Vignesh's patch for "describe related" changes needs a rebase. Can > > > you do that, Vignesh? Meanwhile, I will close all the open comments > > > and try to share a new version by EOD today. > > > > Here is the rebased version of the patch attached. > > Please find attached the latest patch. I have reordered the series, > moving 0006 to 0002, and updated the lock restrictions. We now allow > ACCESS SHARE mode exclusively to ensure pg_dump can acquire its > necessary locks, while blocking higher-level locks to prevent > interference with insertions into the conflict log tables. While reviewing operations on the pg_conflict schema, I noticed a few behaviors that I wasn't sure were intentional. 1. REINDEX is allowed on conflict log tables postgres=3D# REINDEX TABLE pg_conflict.pg_conflict_log_16404; REINDEX I was not sure whether allowing REINDEX on conflict log tables is intentional, given that these are system-managed tables. 2. Views are disallowed, but functions are allowed Creating a view in the pg_conflict schema is rejected: postgres=3D# CREATE VIEW v1 AS SELECT * FROM pg_conflict.pg_conflict_log_16435; ERROR: permission denied to create "pg_conflict.v1" DETAIL: Conflict schema modifications are currently disallowed. However, creating a function in the same schema succeeds: CREATE FUNCTION pg_conflict.get_conflict_count() RETURNS bigint LANGUAGE sql AS $$ SELECT count(*) FROM pg_conflict.pg_conflict_log_16404; $$; CREATE FUNCTION I noticed similar behavior with the pg_toast schema as well, where function creation is allowed: CREATE FUNCTION pg_toast.get_toast_1213_count() RETURNS bigint LANGUAGE sql AS $$ SELECT count(*) FROM pg_toast.pg_toast_1213; $$; CREATE FUNCTION I am not sure what the rationale is for permitting some object types while rejecting others. 3. Functions can be created, but triggers cannot: Although function creation succeeds, trigger creation on a conflict log table is rejected: CREATE TRIGGER conflict_audit AFTER INSERT ON pg_conflict.pg_conflict_log_16435 FOR EACH ROW EXECUTE FUNCTION get_conflict_count(); ERROR: permission denied: "pg_conflict_log_16435" is a conflict log table DETAIL: Conflict log tables are system-managed tables for logical replication conflicts. Again, I wasn't sure whether this distinction is intentional. 4. User-defined types and domains are allowed CREATE TYPE pg_conflict.conflict_status AS ENUM ('ACTIVE', 'INACTIVE'); CREATE TYPE CREATE DOMAIN pg_conflict.positive_int AS integer CHECK (VALUE > 0); CREATE DOMAIN I was also surprised that creating types and domains is permitted in the pg_conflict schema. Overall, I am having some difficulty understanding the rules governing which operations are allowed and which are disallowed in the pg_conflict namespace. If these behaviors are intentional, would it make sense to document the supported and unsupported operations more clearly? That would help avoid confusion for users. Regards, Vignesh