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

Hi,

On 2020-04-02 11:47:32 -0700, Mark Dilger wrote:
> I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs
> as an internal implementation and storage detail only, but we still
> have user facing views that don't treat it that way.

Note that epochs are not really a thing internally anymore. The xid
counter is a FullTransactionId.

> pg_stat_get_activity still returns backend_xid and backend_xmin as
> 32-bit, not 64-bit. Should this function change to be consistent? I'm
> curious what the user experience will be during the transitional period
> where some user facing xids are 64 bit and others (perhaps the same xids
> but viewed elsewhere) will be 32 bit. That might make it difficult for
> users to match them up.

I think we probably should switch them over at some point, but I would
strongly advise against coupling that with Thomas' patch. That patch
doesn't make the current situation around 32bit / 64bit any worse, as
far as I can tell.

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.

Greetings,

Andres Freund