Re: Proposal: Conflict log history table for Logical Replication

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: Narayanan Venkateswaran <narayananvpostgres(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, saurabh singh <saurabh(dot)singh214(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Conflict log history table for Logical Replication
Date: 2026-10-05 09:33:48
Message-ID: CAFiTN-sijgBr7JyoGGi8uxzpbCBSVcpCHi06-A+7MA+McSqiyw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 5, 2026 at 10:56 AM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> On Thu, Oct 1, 2026 at 4:51 PM Narayanan Venkateswaran
> <narayananvpostgres(at)gmail(dot)com> wrote:
> >
> > Hi Nisha,
> >
> > * Thank you very much for the work.
> >
> > >
> > > I’ve addressed these changes in the top-up 004 patch. Dilip, please
> > > consider if it looks good to you.
> > > Patches 001 to 003 are unchanged.
> >
> > * I had two more comments on v77. I sent the email with the additional
> > comments as a follow-up to my first email. Can you please confirm you
> > are able to see those comments too ?
> >
> > >
> > > [1] https://www.postgresql.org/message-id/CABdArM4H_ZVc3%3DpDe4PB-qk4XbWA%3DDLC0SF2_vunz1%2BodGPLPg%40mail.gmail.com
> > >
>
> Thanks, Narayana, for pointing this out. I missed responding to that
> email earlier. Please find my responses inline to both comments below.
>
> On Wed, Sep 30, 2026 at 2:19 AM Narayanan Venkateswaran
> <narayananvpostgres(at)gmail(dot)com> wrote:
> >
> > Thank you once again for the great work, please find some more comments on v77 series of patches below,
> >
> > 1. build_local_conflicts_json_array() still uses row_to_json(). Can we apply the same changes from v77-0002 in this place too ?
> >
> > /*
> > * Builds the local conflicts JSON array column from the list of
> > * ConflictTupleInfo objects.
> > *
> > * Example output structure:
> > * [ { "xid": "1001", "commit_ts": "...", "origin": "..." }, ... ]
> > */
> > static Datum
> > build_local_conflicts_json_array(List *conflicttuples)
> > {
> > .
> > .
> > .
> > .
> > /*
> > * Build the higher level JSON datum in format described in function
> > * header.
> > */
> > json_datum = DirectFunctionCall1(row_to_json, datum);
> > .
> > .
> > .
> > }
> >
>
> The concern in v77-0002 was a user-defined cast to json on a
> user-defined type, which row_to_json() would call. That can't happen
> in local_conflicts - its fields have fixed built-in types (xid,
> timestamptz, text), and each is small and bounded (the origin name is
> at most 512 bytes). So row_to_json() is safe here.
>
> > 2. Minor nit:
> >
> > The commit message in v77-0001 states:
> >
> > The JSON array uses the following structured format:
> > [ { "xid": "1001", "commit_ts": "2025-12-25 10:00:00+05:30", "origin": "node_1",
> > "tuple": {"id": 1, "val": "old_data"} }, ... ]
> >
> > In the code below however, there are only 3 fields: xid, commit_ts, and origin. There is no "tuple" attribute,
> >
> > /*
> > * Schema for the elements within the 'local_conflicts' JSON array.
> > */
> > static const ConflictLogColumnDef LocalConflictSchema[] =
> > {
> > {.attname = "xid", .atttypid = XIDOID},
> > {.attname = "commit_ts", .atttypid = TIMESTAMPTZOID},
> > {.attname = "origin", .atttypid = TEXTOID}
> > };
> >
> > Can we please consider changing the commit message in v77-0001 ?
> >
>
> Agree. 001 needs a commit message update since we opted for the
> option-2 design [1], and I missed updating it when posting v75. This
> can be addressed in the next version, rather than posting a new
> version just for this.

Right, and I think we should also merge these patches, but I am
waiting for the review of them as independent patches, I think 0004
should definitely be merged and also 0002 and 0003 should be combined
into a single overflow handling patch.

--
Regards,
Dilip Kumar
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Bertrand Drouvot 2026-10-05 09:20:27 Re: WAL segment file descriptor leak on read errors can PANIC the server