public inbox for [email protected]  

help / color / mirror / Atom feed

From: shveta malik <[email protected]>
To: Nisha Moond <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: shveta malik <[email protected]>
Subject: Re: Improve conflict detection when replication origins are reused
Date: Wed, 20 May 2026 09:37:39 +0530
Message-ID: <CAJpy0uCTCxKSfXoDh=Rbo6W=O-VbDXHz6j7DJS0DZekzyM9qqw@mail.gmail.com> (raw)
In-Reply-To: <CABdArM5JNKtybXesmiPCFZ=B8MqkxQ-2SZzpgjfu2EnE8kq-yw@mail.gmail.com>
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>

On Tue, May 19, 2026 at 7:08 PM Nisha Moond <[email protected]> wrote:
>
> 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.
>

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

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: <CAJpy0uCTCxKSfXoDh=Rbo6W=O-VbDXHz6j7DJS0DZekzyM9qqw@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