Hi,
On 2020-04-17 13:33:53 -0400, Robert Haas wrote:
> On Thu, Apr 2, 2020 at 5:13 PM Andres Freund <andres@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