MIME-Version: 1.0
References: 
 <CABdArM5k7wCxq+L2r9-mLOoPXe_iHgdeRMXc31oxvzSj=xPjFQ@mail.gmail.com>
 <CAJpy0uD-pjcDfd2z-E-LF_newxj47zYLktDsQX_H+JTCzEk4cw@mail.gmail.com>
 <CABdArM5JNKtybXesmiPCFZ=B8MqkxQ-2SZzpgjfu2EnE8kq-yw@mail.gmail.com>
In-Reply-To: 
 <CABdArM5JNKtybXesmiPCFZ=B8MqkxQ-2SZzpgjfu2EnE8kq-yw@mail.gmail.com>
From: shveta malik <shveta.malik@gmail.com>
Date: Wed, 20 May 2026 09:37:39 +0530
Message-ID: 
 <CAJpy0uCTCxKSfXoDh=Rbo6W=O-VbDXHz6j7DJS0DZekzyM9qqw@mail.gmail.com>
Subject: Re: Improve conflict detection when replication origins are reused
To: Nisha Moond <nisha.moond412@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	shveta malik <shvetamalik@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJpy0uCTCxKSfXoDh%3DRbo6W%3DO-VbDXHz6j7DJS0DZekzyM9qqw%40mail.gmail.com>
Precedence: bulk

On Tue, May 19, 2026 at 7:08=E2=80=AFPM Nisha Moond <nisha.moond412@gmail.c=
om> wrote:
>
> On Tue, May 19, 2026 at 2:52=E2=80=AFPM 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