Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From Peter Smith
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAHut+Pv6ROpBaiYXojbudjiehtaE3imSURFHj5NJVXa=BNdtqw@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (vignesh C <vignesh21@gmail.com>)
Responses Re: Proposal: Conflict log history table for Logical Replication
List pgsql-hackers
On Mon, Jun 8, 2026 at 9:39 PM vignesh C <vignesh21@gmail.com> wrote:
>
> On Fri, 5 Jun 2026 at 07:59, Peter Smith <smithpb2250@gmail.com> wrote:
> >
> > Hi Vignesh.
> >
> > Some review comments for the patch v45-0004.
> >
> > 4c.
> > IMO there should be a separate function for handling the subscription
> > footer/s, same as there is already a function
> > addFooterToPublicationDesc.
>
> It is not required in this case as we don't have multiple footers from
> different places to be added here.
>

Sure, it's not "required", but I think:
A) Separating the footer code from the non-footer code makes it easier to read
B) The 'describeSubscriptions' function is too long. This would make
it 20 lines shorter.
C) Consistent footer handling for pub/sub describes.

//////

More review comments for v50-0005

======
src/bin/psql/describe.c

1.
+ /* Conflict log destination is supported in v19 and higher */
+ if (pset.sversion >= 190000)

The CLT is targeting PG20, right? So, that comment ought to say "is
supported in v20 and higher".

Ideally, there should be some "TODO" reminder comments here to ensure
the appropriate 190000's get replaced by 200000 as soon as the version
number is bumped. Better to flag/comment all those places now, so that
nothing gets missed later.

(A similar review comment probably applies also to the pg_dump changes
in the previous v50-0004 patch).

======
Kind Regards,
Peter Smith.
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Dead reference to schema_only_with_statistics in pg_dump TAP code
Next
From: Jeff Davis
Date:
Subject: Re: Avoid orphaned objects dependencies, take 3