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
