Re: Proposal: Conflict log history table for Logical Replication

On Wed, Jun 17, 2026 at 11:58 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> 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.

yeah, I shared this point earlier in [1]. I guess it's missed.

>
> > 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?

I have the same opinion. Also I raised the same question about table
names. The behaviour should be conssitent for tables, views. Please
see my responses in [1]. Also see my comment #2 in [2] for
table-creation inside CLT.

[1]: https://www.postgresql.org/message-id/CAJpy0uDoa0CYWkxj52h%3DRM53acfsqjRihCfKrm8W%3DvRvHg01UA%40mail.gmail.com
[2]: https://www.postgresql.org/message-id/CAJpy0uCoVPRvaAwgDz1EZww1PqHUd4B%3DS%2BF1Dh2F9kxKMpvJEw%40mail.gmail.com

thanks
Shveta