Thread

Re: Improve conflict detection when replication origins are reused

Nisha Moond <nisha.moond412@gmail.com> — 2026-05-19T13:38:22Z

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.

--
Thanks,
Nisha