On Fri, Feb 20, 2026 at 4:35 PM Hayato Kuroda (Fujitsu) <[email protected]> wrote: > > > One of > > the use case I recall is to detect conflicts with accuracy after > > upgrade. See docs [1] ("Commit timestamps and origin data are not > > preserved during the upgrade. ..) I think this note needs an update > > after this patch. > > Right, and code comments [a] should be also updated. >
So, leaving aside update_delete, copying commit_ts could be helpful to detect some other conflicts. You may want to once test the same and show it here as part of use case establishment. > BTW, is there a possibility that we can export and import xmin of the conflict > slot to retain dead tuples even after the upgrade? Of course it's out-of-scope > from this thread. > Yeah, this is a good point to explore separately. The key thing we need to evaluate is whether the rows corresponding to old_xids are retained. We probably need to evaluate the epoch part as well in old cluster's slot. We do call set_frozenxids() for new cluster that might have some impact on the functionality you are looking at. > > Also, _on in the variable name appears bit odd. > > I have two options, thought? > - commit_ts_is_enabled, This looks reasonable to me. -- With Regards, Amit Kapila.
