Re: Proposal: Conflict log history table for Logical Replication
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Peter Smith <smithpb2250@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>,
shveta malik <shveta.malik@gmail.com>
Date: 2025-11-26T08:35:48Z
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 Tue, Nov 25, 2025 at 4:06 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > On Tue, Nov 25, 2025 at 1:59 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On a separate note, I've been considering how to manage conflict log > insertions when an error causes the outer transaction to abort, which > seems to be a non-trivial. > > Here is what I have in mind: > ====================== > First, prepare_conflict_log() would be executed from > ReportApplyConflict(). This function would handle all preliminary > work, such as preparing the tuple for the conflict log table. Second, > insert_conflict_log() would be executed. If the error level in > ReportApplyConflict() is LOG, the insertion would occur directly. > Otherwise, the log information would be stored in a global variable > and inserted in a separate transaction once we exit start_apply() due > to the error. > > @shveta malik @Amit Kapila let me know what you think? Or do you > think it can be simplified? > I could not think of a better way. This idea works for me. I had doubts if it will be okay to start a new transaction in catch-block (if we plan to do it in start_apply's), but then I found few other functions doing it (see do_autovacuum, perform_work_item, _SPI_commit). So IMO, we should be good. thanks Shveta