Re: Proposal: Conflict log history table for Logical Replication

On Tue, Jun 16, 2026 at 4:12 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> o ensure we are aligned, I want to clarify the current behavior before
> we decide on the next steps. Currently, view and function creation are
> both permitted for toast and conflict tables. However, there is a
> discrepancy in the schemas: view creation is blocked in the
> 'pg_conflict' and 'pg_toast' schemas, while function creation is
> allowed in both. So IIUC we need to take a call whether the function
> creation should be blocked in pg_conflict schema or not, logically we
> can say it can be blocked but we might need to discuss on this because
> it's allowed in the `pg_toast` schema. And if we are worried about
> the descripency that functions are allowed in this schema but views
> are not, I don't think we need to worry about this, this is an
> existing behaviour for toast also and if we want to can investigate as
> a separate thread and fix it for system schema al together? Am I
> missing something here?
>
> postgres[2205601]=# CREATE VIEW v2 AS select * from pg_toast.pg_toast_16412;
> CREATE VIEW
>
> postgres[2205601]=# CREATE VIEW v3 AS select * from
> pg_conflict.pg_conflict_log_16406;
> CREATE VIEW
>
> CREATE VIEW pg_toast.v5 AS select * from pg_toast.pg_toast_16412;
> ERROR: 42501: permission denied to create "pg_toast.v5"
> DETAIL: System catalog modifications are currently disallowed.
> LOCATION: heap_create, heap.c:322
>
> postgres[2205601]=# CREATE VIEW pg_conflict.v5 AS select * from
> pg_conflict.pg_conflict_log_16406;
> ERROR: 42501: permission denied to create "pg_conflict.v5"
> DETAIL: Conflict schema modifications are currently disallowed.
> LOCATION: heap_create, heap.c:329
>

The one case which is not shared is allow_system_table_mods = on mode
where I think the view is allowed to create in pg_toast but not in
pg_conflict schema.

> postgres[2205601]=# CREATE FUNCTION pg_conflict.get_conflict_count()
> RETURNS bigint
> LANGUAGE sql
> AS $$
> SELECT count(*) FROM pg_conflict.pg_conflict_log_16406;
> $$;
> CREATE FUNCTION
>
> postgres[2205601]=# CREATE FUNCTION pg_toast.get_toast_count()
> RETURNS bigint
> LANGUAGE sql
> AS $$
> SELECT count(*) FROM pg_toast.pg_toast_16412;
> $$;
> CREATE FUNCTION
>

I think we should allow both functions and views in non-pg_conflict
schema and disallow both in pg_conflict schema. This is because there
is no use case of allowing user objects in pg_conflict schema (even
with allow_system_table_mods) and we have deliberately kept it closed
for user objects. The one minor advantage in keeping closed for user
objects is that we can avoid the risk of name collisions in
pg_conflict schema. Will this address questions/concerns raised on
this topic?

--
With Regards,
Amit Kapila.