public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nisha Moond <[email protected]>
To: shveta malik <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: Improve conflict detection when replication origins are reused
Date: Tue, 19 May 2026 19:08:22 +0530
Message-ID: <CABdArM5JNKtybXesmiPCFZ=B8MqkxQ-2SZzpgjfu2EnE8kq-yw@mail.gmail.com> (raw)
In-Reply-To: <CAJpy0uD-pjcDfd2z-E-LF_newxj47zYLktDsQX_H+JTCzEk4cw@mail.gmail.com>
References: <CABdArM5k7wCxq+L2r9-mLOoPXe_iHgdeRMXc31oxvzSj=xPjFQ@mail.gmail.com>
<CAJpy0uD-pjcDfd2z-E-LF_newxj47zYLktDsQX_H+JTCzEk4cw@mail.gmail.com>
On Tue, May 19, 2026 at 2:52 PM shveta malik <[email protected]> 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Improve conflict detection when replication origins are reused
In-Reply-To: <CABdArM5JNKtybXesmiPCFZ=B8MqkxQ-2SZzpgjfu2EnE8kq-yw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox