Hi, On 2020-04-02 14:26:41 -0700, Mark Dilger wrote: > Since Thomas's patch is really just focused on transitioning from txid > -> xid8, I think this conversation is a bit beyond scope for this > patch, except that "xid8" sounds an awful lot like the new type that > all user facing xid output will transition to. Maybe I'm wrong about > that.
Several at least. For me it'd e.g. make no sense to change pageinspect etc. > Are we going to change the definition of the "xid" type to 8 bytes? > That sounds dangerous, from a compatibility standpoint. No, I can't see that happening. > On balance, I'd rather have xid8in and xid8out work just as Thomas has > it. I'm not asking for any change there. But I'm curious if the > whole community is on the same page regarding where this is all > heading. > > I'm contemplating the statement that "the goal should be to reduce > awareness of the 32bitness of normal xids from as many places as > possible", which I support, and what that means for the eventual > signatures of functions like pg_stat_get_activity, including: Maybe. Aiming to do things like this all-at-once just makes it less likely for anything to ever happen. > but otherwise there would be a transition period where some have been > reworked to return xid8 but others not, and users during that > transition period might be happier with Alvaro's suggestion of > treating epoch/xid as two fields in xid8in and xid8out. -countless I can only restate my point that we've had 8 byte xids exposed for many years. We've had very few epoch/xid values exposed. I think it'd be insane to now start to expose that more widely. It's just about impossible for normal users to compare xids. Once one wrapped around, it's just too hard/mindbending. Yes, an accompanying epoch makes it easier, but it still can be quite confusing. Greetings, Andres Freund
