Thread

Re: Proposal: Conflict log history table for Logical Replication

vignesh C <vignesh21@gmail.com> — 2026-05-21T07:11:03Z

On Thu, 21 May 2026 at 05:32, Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Wed, May 20, 2026 at 8:50 PM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
> ..
> > Comments for 0002:
> > 2. We can rename the schema pg_conflict to a different schema name.
> > Is it ok to hardcode the schema name to 'pg_conflict'?
> > -                errmsg("cannot move objects into or out of CONFLICT schema")));
> > +                errmsg("cannot move objects into or out of
> > pg_conflict schema")));
> >
> > Example:
> > postgres=# ALTER SCHEMA pg_conflict RENAME TO sc1;
> > ALTER SCHEMA
> > postgres=# ALTER TABLE t2 SET SCHEMA sc1;
> > ERROR:  cannot move objects into or out of pg_conflict schema
> >
>
> Yikes!
>
> I am not sure that the error message is the problem here. There are
> worse things that are similar to this. e.g. I found that you can do
> the same trick of renaming the 'pg_catalog' schema, and it breaks
> anything that refers to that schema by name -- all the internal SQL!!
>
> test_pub=# ALTER SCHEMA pg_catalog RENAME TO mycatalog;
> ALTER SCHEMA
> test_pub=# \dRp+
> ERROR:  relation "pg_catalog.pg_publication" does not exist
> LINE 9: FROM pg_catalog.pg_publication
>              ^

I noticed this behavior with several other commands as well. For example:
postgres=# ALTER SCHEMA pg_catalog RENAME TO test;
ALTER SCHEMA
postgres=# \d
ERROR:  relation "pg_catalog.pg_class" does not exist
LINE 6: FROM pg_catalog.pg_class c
             ^
postgres=# \dn
ERROR:  relation "pg_catalog.pg_namespace" does not exist
LINE 4: FROM pg_catalog.pg_namespace n
             ^

I observed similar behavior when creating a table in the renamed schema:
postgres=# CREATE TABLE test.t1(c1 int);
ERROR:  schema "pg_catalog" does not exist
LINE 1: CREATE TABLE test.t1(c1 int);
                     ^

Given that this appears to be a broader issue related to renaming
pg_catalog, I think we can skip handling this case for now. If we
decide to address it, it would be better to handle it together with
the general pg_catalog rename behavior.

Regards,
Vignesh