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
