Re: Proposal: Conflict log history table for Logical Replication
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: vignesh C <vignesh21@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>,
Peter Smith <smithpb2250@gmail.com>
Date: 2026-01-07T10:56:26Z
Lists: pgsql-hackers
On Wed, Jan 7, 2026 at 12:12 PM shveta malik <shveta.malik@gmail.com> wrote: > > Hi Dilip, > Please find a few comments on v19-001: > > 1) > We can replace IsConflictLogTable(relid) with > IsConflictClass(reltuple). Wherever we call IsConflictLogTable(), we > have already fetched reltuple from pg_class for that relid, we can > simply use that to see if it belongs to pg_conflict namespace. That > will avoid the need of > patch004 as well to 'Introduce a dedicated shared unique index on > pg_subscription.subconflictlogrelid'. > > 2) > + if (opts.logdest == CONFLICT_LOG_DEST_TABLE || > + opts.logdest == CONFLICT_LOG_DEST_ALL) > > We can replace with: > > IsSet(opts.logdest, CONFLICT_LOG_DEST_TABLE); > > 3) > +-- this should generate an internal table named pg_conflict_$subid$ > +CREATE SUBSCRIPTION regress_conflict_test1 CONNECTION > 'dbname=regress_doesnotexist' PUBLICATION testpub WITH (connect = > false, conflict_log_destination = 'table'); > + > > I think we shall verify 2 things here: > a) Table is created in pg_conflict namespace. > b) Table has name pg_conflict_<subid> > > 4) > We can add these 3 simple tests as well: > a) Trying to alter and truncate pg_conflict_subid table. > b) Trying to create a new table in pg_conflict namespace. > c) Moving a table into pg_conflict namespace. > > ~~ > > Overall, I’m concerned about how users will manage this table as it > grows. There is currently no way to purge old data, truncation is > disallowed, and the table must be sub-ID–tied, which also prevents > users from attaching a different table as a CLT (if needed). > Additionally, we do not offer any form of partitioning. > Do you think we should provide users with a basic purge mechanism? At > the very least, should we allow truncation so users can take a backup > and truncate a sub-ID–tied CLT to start afresh? Thoughts? Yeah that's a valid concern, there should be some way to purge data from this table, I think we can allow truncate/delete on this table, currently I haven't blocked the DML operations on that table and similarly we can allow truncate as well. -- Regards, Dilip Kumar Google
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