Re: Proposal: Conflict log history table for Logical Replication
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-24T11:40:17Z
Lists: pgsql-hackers
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
On Wed, Sep 24, 2025 at 4:00 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Tue, Sep 23, 2025 at 11:29 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Sat, Sep 20, 2025 at 4:59 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > > > AFAIR, one open point for internally created tables is whether we > > > should skip changes to conflict_history table while replicating > > > changes? The table will be considered under for ALL TABLES > > > publications, if defined? Ideally, these should behave as catalog > > > tables, so one option is to mark them as 'user_catalog_table', or the > > > other option is we have some hard-code checks during replication. The > > > first option has the advantage that it won't write additional WAL for > > > these tables which is otherwise required under wal_level=logical. What > > > other options do we have? > > > > I think conflict history information is subscriber local information > > so doesn't have to be replicated to another subscriber. Also it could > > be problematic in cross-major-version replication cases if we break > > the compatibility of history table definition. > > > > Right, this is another reason not to replicate it. > > > I would expect that the > > history table works as a catalog table in terms of logical > > decoding/replication. It would probably make sense to reuse the > > user_catalog_table option for that purpose. If we have a history table > > for each subscription that wants to record the conflict history (I > > believe so), it would be hard to go with the second option (having > > hard-code checks). > > > > Agreed. Let's wait and see what Dilip or others have to say on this. Yeah I think this makes sense to create as 'user_catalog_table' tables when we internally create them. However, IMHO when a user provides its own table, I believe we should not enforce the restriction for that table to be created as a 'user_catalog_table' table, or do you think we should enforce that property? -- Regards, Dilip Kumar Google