Re: Should we add xid_current() or a int8->xid cast?

On Fri, Apr 3, 2020 at 10:37 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2020-04-02 14:26:41 -0700, Mark Dilger wrote:
> > 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.

Agreed. Let's just keep chipping away at this stuff.

> > 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.

Just by the way, any xid8 values can be sliced with ::xid, so that
should help with comparisons. I'm not keen to allow users to convert
in the other direction though, due to the hard-to-understand
interlocking requirements of modulo xids (as belaboured elsewhere).

As Mark noted, I'd left a few uses of txid_XXX stuff in other tests.
So here's a 0003 patch that upgrades all of those too, so that the
only remaining usage is in the txid.sql tests (= the tests that the
backwards compat functions still work). No change to 0001 and 0002,
other than a commit message tweak (reviewer email address change).