On Sat, 13 Jun 2026 at 15:46, Dilip Kumar <[email protected]> wrote:
>
> On Thu, Jun 11, 2026 at 5:53 PM vignesh C <[email protected]> wrote:
> >
> > On Thu, 11 Jun 2026 at 10:44, Dilip Kumar <[email protected]> wrote:
> > >
> > > Please find the rebased patch
> > > 1. It includes the new 0005 patch for reporting errors for DDLs on clt.
> > >
> > > 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=# 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=# 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
