Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

On Mon, Jan 12, 2026 at 7:51 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Jan 9, 2026 at 7:13 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Fri, Jan 9, 2026 at 12:42 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > On Mon, 5 Jan 2026 at 15:13, Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > >
> > > > Here is the updated version of patch
> > >
> > > I would like to suggest renaming the newly introduced system schema
> > > from pg_conflict to pg_logical or something in lines of logical
> > > replication.
> > > Although the immediate use case is conflict logging, the schema is
> > > fundamentally part of the logical replication subsystem. A broader
> > > name such as pg_logical provides a more appropriate and future proof
> > > namespace. In contrast, a feature-specific name like pg_conflict is
> > > risky as logical replication evolves and could necessitate the
> > > introduction of additional system schemas later. Looking ahead,
> > > advanced features such as DDL replication or multi-node writes would
> > > likely require metadata for cluster topology of multiple nodes, leader
> > > state, peer discovery, and resolution policies for node failure. This
> > > type of replication specific metadata would naturally fit under a
> > > pg_logical system schema rather than pg_catalog.
> > >
> > > Finally, adopting pg_logical would leave open the possibility of
> > > logically grouping existing logical replication catalogs and views
> > > (publications, subscriptions, and slot related information) under a
> > > single subsystem namespace, instead of having them scattered across
> > > pg_catalog.
> >
> > I agree with this analysis of making it future proof what others think
> > about this?  Although we might not be clear now what permission
> > differences would be needed for future metadata tables compared to
> > conflict tables, those could be managed if we get the generic name.
> >
>
> Why do you think this additional meta-data can't reside in the
> pg_catalog schema as we have for other system tables? IIUC, we are
> planning to have a pg_conflict schema for the conflict history table
> because we want a different treatment for pg_dump (like we want to
> dump its data during upgrade) and some permissions for user access to
> it (say for purging data from this table).

Yeah that make sense.

 AFAICS, the other meta-data
> mentioned above shouldn't have any such specific needs unless I am
> missing something. It is not that I am against naming it differently
> or using some generic name but I can't see a reason for it. Instead,
> following a path like we already have for pg_toast (where schema name
> indicates its purpose) sounds like a better fit.

So maybe we should continue with the pg_conflict name itself.  Lets
see what Vignesh has to say as he has raised this concern.

--
Dilip



--
Regards,
Dilip Kumar
Google