Thread

Re: Proposal: Conflict log history table for Logical Replication

Dilip Kumar <dilipbalaut@gmail.com> — 2026-05-06T14:04:57Z

On Wed, May 6, 2026 at 6:28 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Wed, May 6, 2026 at 4:31 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, May 6, 2026 at 3:01 PM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > 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.
> > >
> >
> > I think we shouldn't go out of our way to disallow superusers to
> > rename pg_conflict schema similar to other cases. We can try to
> > prevent hard-coding schema names where possible but not sure we can
> > guarantee that nothing related to pg_conflict schema won't break as
> > shown by you in the following similar case for pg_conflict.
> >
> > > 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
>
> I can see pg_toast and pg_catalog schema also hard coded in couple of
> places e.g.
>
> listPartitionedTables()
> {
> if (!pattern)
> appendPQExpBufferStr(&buf, " AND n.nspname <> 'pg_catalog'\n"
> " AND n.nspname !~ '^pg_toast'\n"
> " AND n.nspname <> 'information_schema'\n");
> }
>
> I will analyze which all places we are hardcoding, I think on server
> side code we can easily avoid but from client side e.g. describe we
> might need to invent a way to identify the schema name, or we might
> have to store it somewhere in pg_subscription etc, I don't think we
> should go that route.

Here is updated patch set

Open comments:
1. Analyze and avoid hardcoding the 'pg_conflict' schema name wherever possible
2. change the way we display clt in \dRs+
3. Transfer the clt ownership when subscription ownership has change
(Note: I have coded a poc for this but still checking whether it works
in all cases)

I will send the revised version by end of this week after fixing these
open comments as well.



-- 
Regards,
Dilip Kumar
Google