Re: Proposal: Conflict log history table for Logical Replication

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). 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.

-- 
With Regards,
Amit Kapila.