Re: Proposal: Conflict log history table for Logical Replication

On Mon, 12 Jan 2026 at 17:18, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Mon, Jan 12, 2026 at 7:51 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Fri, Jan 9, 2026 at 7:13 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > On Fri, Jan 9, 2026 at 12:42 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> > > >
> > > > On Mon, 5 Jan 2026 at 15:13, Dilip Kumar <dilipbalaut(at)gmail(dot)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.

My intent in raising the point was mainly to sanity check the naming,
given that we generally avoid introducing new system schemas, and
since we are doing so here, I wanted to ensure the name is reasonably
future proof. I agree that the immediate motivation for a separate
schema is driven by the specific requirements for conflict history,
and in that context pg_conflict is a clear and purpose driven name,
similar to how pg_toast reflects its use case. Looking ahead, it
seems reasonable that future features such as DDL replication would
either place their metadata in pg_catalog, with conflict related
information continuing to live in pg_conflict, or otherwise fit
naturally within this split. I couldn't identify a concrete future use
case that would not fit well into pg_catalog and/or pg_conflict. Given
that, I’m fine with proceeding with the pg_conflict naming.

Regards,
Vignesh