Re: Proposal: Conflict log history table for Logical Replication
vignesh C <vignesh21@gmail.com>
From: vignesh C <vignesh21@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>,
Nisha Moond <nisha.moond412@gmail.com>, shveta malik <shveta.malik@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-06-24T12:24:35Z
Lists: pgsql-hackers
On Wed, 24 Jun 2026 at 16:32, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Wed, Jun 24, 2026 at 12:53 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> >
> > On Tue, Jun 23, 2026 at 2:22 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > Few comments:
> > > 1) Currently we are storing these in shared memory. Looking at the
> > > implementation, these fields are purely worker-private state used to
> > > ferry data across the error boundary from prepare_conflict_log_tuple()
> > > (inside the PG_TRY block) to ProcessPendingConflictLogTuple() (inside
> > > the PG_CATCH block).
>
> Good point.
>
> If it is not required by another process, should
> > > it be moved out of shared memory.
> > > + /* A conflict log tuple that is prepared but not yet inserted. */
> > > + HeapTuple conflict_log_tuple;
> > > +
> > > + /*
> > > + * Error-context string describing the conflict above, used to
> > > annotate any
> > > + * error raised while inserting conflict_log_tuple into the conflict log
> > > + * table. Allocated, like conflict_log_tuple, in ApplyContext.
> > > + */
> > > + char *conflict_log_errcontext;
> >
> > Yeah there is no need for them to be in shared memory, but do we have
> > any other data sturcture where these fits naturally, or we can make
> > them global variables?
> >
>
> Or we can have a file local struct PendingConflictLogData similar to
> FlushPosition. See the attached top-up patch. As the comment
> ("Allocated, like conflict_log_tuple, in ApplyContext") says it is
> allocated in process-local Apply context, it is not safe to keep them
> in shared memory.
These approach looks good, couple of minor comments can be done while
merging the patch:
1) Generally we keep the typedef name and struct name same:
+typedef struct PendingConflictLogData
+{
+ HeapTuple tuple; /* prepared,
not-yet-inserted conflict tuple */
+ char *errcontext_str; /* conflict description for
error context */
+} PendingConflictLog;
2) PendingConflictLog should be included in typedefs.list
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