Thread

Re: Improve conflict detection when replication origins are reused

shveta malik <shveta.malik@gmail.com> — 2026-05-20T04:07:39Z

On Tue, May 19, 2026 at 7:08 PM Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> On Tue, May 19, 2026 at 2:52 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > I find Approach 2 the most practical. I explored other ideas but none
> > seem completely reliable or worth the effort to justify this use-case.
> > A few ideas I considered are:
> >
> > 1) We could modify replorigin_create to exhaust the full range of IDs
> > sequentially before reusing them. But this is not a reliable solution.
> > It would make the bug much harder to hit, but a busy system could
> > still eventually exhaust the 2-byte limit of 65K IDs, after which the
> > problem may reappear.
> >
> > 2) Using LSN Matching instead of timestamp. To completely eliminate
> > the edge case where a timestamp results in a false-positive case, we
> > could track the origin_creation_lsn and compare it against the tuple's
> > commit LSN. IIUC, it would require extending commit_ts to include
> > 8-byte of commit-lsn which might not be a good idea. So this idea may
> > also not be desirable unless there is an existing way to extract
> > commit-lsn (which I am not aware of) without extending the commit-ts
> > structure?
> >
>
> Using LSN is a good idea. I looked through the code a bit, and
> extending `commit_ts` seems like the only option. I also could not
> find anything existing from which we can extract the commit LSN of a
> tuple while applying a change.
> Every heap page has pd_lsn (accessible via PageGetLSN(page)), which
> stores the LSN of the most recent WAL record that modified the page.
> But this doesn't help, as there is no correlation to a specific
> tuple's xmin.
>

Even I could not find any existing way to get the commit-LSN. We have
TransactionIdGetCommitLSN() but this does not return exact commit-lsn.

thanks
Shveta