| From: | Zhijie Hou <houzhijie22(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | shveta malik <shveta(dot)malik(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, shihao zhong <zhong950419(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, vignesh C <vignesh21(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>, shveta malik <shvetamalik(at)gmail(dot)com> |
| Subject: | Re: Proposal: Conflict log history table for Logical Replication |
| Date: | 2026-11-03 14:37:04 |
| Message-ID: | CAFvd2n94aFyERO0oAXn5E9L+0WA-HS+SPaMtnjR5g5KwY=0itw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Tue, Nov 3, 2026 at 6:46 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Nov 3, 2026 at 3:17 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Tue, Nov 3, 2026 at 1:47 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > > ---
> > > Is there any way to carry over CLT data across major versions?
> > >
>
> Yes, there is a patch for this which is under discussion earlier, see
> [1] but we thought we can deal with insertion as a pre-step and then
> review that more care fully.
I've attached those pending patches in the latest patch set for reference.
Thanks Vignesh, for rebasing the patch and sharing it off-list.
> > > ---
> > > The xid in local_conflicts is a 32-bit xid. I think it's better to
> > > record a FullTransactionId instead. Otherwise, after xid wraparound,
> > > two different local transactions can be recorded with the same xid,
> > > which would easily confuse monitoring queries. We can't do the same
> > > for remote_xid since the protocol sends only a 32-bit xid, but it
> > > might be worth documenting.
> > >
>
> Agreed.
I also agree, and I'll analyze and test the race condition between computing
the full xid and the xid being frozen concurrently, and then change it in the
next version.
Here is the V90 patch set, which addresses the comments we agreed on,
including Narayanan's latest comment.
--
Best Regards,
Zhijie Hou
| Attachment | Content-Type | Size |
|---|---|---|
| v90-0002-Preserve-conflict-log-destination-and-subscripti.patch | application/octet-stream | 25.2 KB |
| v90-0003-Add-conflict-log-table-information-to-describe-s.patch | application/octet-stream | 78.4 KB |
| v90-0001-Record-logical-replication-conflicts-in-the-conf.patch | application/octet-stream | 129.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-11-03 14:51:17 | Re: Test publication.sql racing with subscription.sql might fail due to cache lookup error |
| Previous Message | Greg Burd | 2026-11-03 14:34:16 | Re: [RFC] Property-based testing for Postgres |