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