Horton

Re: Proposal: Conflict log history table for Logical Replication

shveta malik <shveta.malik@gmail.com>

View thread
From: shveta malik <shveta.malik@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, shveta malik <shvetamalik@gmail.com>
Date: 2026-05-06T09:31:30Z
Lists: pgsql-hackers 
On Wed, May 6, 2026 at 9:24 AM vignesh C <vignesh21@gmail.com> wrote:
>
> Few comments:
> 1) Currently we allow renaming of pg_conflict schema, this might be ok
> as we allow other sysem schema like pg_catalog and pg_toast also.
> postgres=# alter schema pg_conflict rename to test_conflict;
> ALTER SCHEMA
>

I agree that we allow renaming other schemas including pg_toast, but I
am not sure if this is consciously made decision, see BUG #18281 ast
[1]. I don't favour allowing renaming pg_conflict for 2 reasons:

1) Because Postgres explicitly blocks renaming schemas to a name
starting with 'pg_'. If an admin accidentally renames 'pg_conflict' to
something else, they are permanently locked out from renaming it back.

2) While the core worker might survive a rename via OID lookups;
external scripts, extensions, and monitoring tools will likely
hardcode the 'pg_conflict' string. If the schema is renamed, these
tools will fail.

One such example  of scripts breaking is present event in Postgres. I
did the following, and most of psql commands started failing after
that due to hard-coded pg_catalog name in them.

postgres=# alter schema pg_catalog rename to catalog_new;
ALTER SCHEMA

postgres=# \d catalog_new.*
ERROR:  relation "pg_catalog.pg_class" does not exist
LINE 5: FROM pg_catalog.pg_class c

[1]: https://www.postgresql.org/message-id/flat/18281-5b1b6c5991d345aa%40postgresql.org

thanks
Shveta