Re: Proposal: Conflict log history table for Logical Replication
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-09T07:12:10Z
Lists: pgsql-hackers
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. Regards, Vignesh
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical replication conflicts to be logged to a table.
- a5918fddf10d master landed
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) cited