On Mon, May 1, 2023 at 8:03 AM Robert Haas <robertmh...@gmail.com> wrote: > To me, the fact that the XID space is circular is the whole point of > talking about wraparound.
The word wraparound is ambiguous. It's not the same thing as xidStopLimit in my view. It's literal integer wraparound. If you think of XIDs as having a native 64-bit representation, while using a truncated 32-bit on-disk representation in tuple headers (which is the view promoted by the doc patch), then XIDs cannot wrap around. There is still no possibility of "the future becoming the past" (assuming no use of single user mode), either, because even in the worst case we have xidStopLimit to make sure that the database doesn't become corrupt. Why talk about what's *not* happening in a place of prominence? We'll still talk about literal integer wraparound with the doc patch, but it's part of a discussion of the on-disk format in a distant chapter. It's just an implementation detail, which is of no practical consequence. The main discussion need only say something succinct and vague about the use of a truncated representation (lacking a separate epoch) in tuple headers eventually forcing freezing. > If the XID space were non-circular, it could > never try to reuse the XID values that have previously been used, and > this entire class of problems would go away. Because it is circular, > it's possible for the XID counter to arrive back at a place that it's > been before i.e. it can wrap around. But integer wrap around isn't really aligned with anything important. xidStopLimit will kick in when we're only halfway towards literal integer wrap around. Users have practical concerns about avoiding xidStopLimit -- what a world without xidStopLimit looks like just doesn't matter. Just having some vague awareness of truncated XIDs being insufficient at some point is all you really need, even if you're an advanced user. -- Peter Geoghegan
