Re: Proposal: Conflict log history table for Logical Replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@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-27T15:23:28Z
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 Fri, Sep 26, 2025 at 4:42 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Thu, Sep 25, 2025 at 4:19 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Thu, Sep 25, 2025 at 11:53 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > [1] > > > > /* > > > > * For logical decode we need combo CIDs to properly decode the > > > > * catalog > > > > */ > > > > if (RelationIsAccessibleInLogicalDecoding(relation)) > > > > log_heap_new_cid(relation, &tp); > > > > > > > > > > Meanwhile I am also exploring the option where we can just CREATE TYPE > > > in initialize_data_directory() during initdb, basically we will create > > > this type in template1 so that it will be available in all the > > > databases, and that would simplify the table creation whether we > > > create internally or we allow user to create it. And while checking > > > is_publishable_class we can check the type and avoid publishing those > > > tables. > > > > > > > Based on my off list discussion with Amit, one option could be to set > > HEAP_INSERT_NO_LOGICAL option while inserting tuple into conflict > > history table, for that we can not use SPI interface to insert instead > > we will have to directly call the heap_insert() to add this option. > > Since we do not want to create any trigger etc on this table, direct > > insert should be fine, but if we plan to create this table as > > partitioned table in future then direct heap insert might not work. > > Upon further reflection, I realized that while this approach avoids > streaming inserts to the conflict log history table, it still requires > that table to exist on the subscriber node upon subscription creation, > which isn't ideal. > I am not able to understand what exact problem you are seeing here. I was thinking that during the CREATE SUBSCRIPTION command, a new table with user provided name will be created similar to how we create a slot. The difference would be that we create a slot on the remote/publisher node but this table will be created locally. -- With Regards, Amit Kapila.