Hi, On 2020-04-17 13:33:53 -0400, Robert Haas wrote: > On Thu, Apr 2, 2020 at 5:13 PM Andres Freund <and...@anarazel.de> wrote: > > Given that txid_current() "always" has been a plain 64 bit integer, and > > the various txid_* functions always have returned 64 bit integers, I > > really don't think arguing for some 32bit/32bit situation now makes > > sense. > > I'm not sure what the best thing to do is here, but the reality is > that there are many places where 32-bit XIDs are going to be showing > up for years to come. With the format printed as a raw 64-bit > quantity, people troubleshooting stuff are going to spend a lot of > time figuring what x%2^32 is. And I can't do that in my head. So I > think saying that the proposal does not makes sense is a gross > overstatement. It may not be what we want to do. But it definitely > would make sense.
You seem to be entirely disregarding my actual point, namely that txid_current(), as well as some other txid_* functions, have returned 64bit xids for many many years. txid_current() is the only function to get the current xid in a reasonable way. I don't understand how a proposal to add a 32/32 bit representation *in addition* to the existing 32 and 64bit representations is going to improve the situation. Nor do I see changing txid_current()'s return format as something we're going to go for. I did not argue against a function to turn 64bit xids into epoch/32bit xid or such. ? Greetings, Andres Freund
