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

> On Apr 2, 2020, at 2:13 PM, Andres Freund <andres@anarazel.de> wrote:
>
> 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.

I agree with that.

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

Yeah, I'm not arguing for that, though I can see how my email might have been ambiguous on that point.

Since Thomas's patch is really just focused on transitioning from txid -> xid8, I think this conversation is a bit
beyondscope for this patch, except that "xid8" sounds an awful lot like the new type that all user facing xid output
willtransition to.  Maybe I'm wrong about that.   Are we going to change the definition of the "xid" type to 8 bytes?
Thatsounds dangerous, from a compatibility standpoint. 

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'mcurious 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
manyplaces as possible", which I support, and what that means for the eventual signatures of functions like
pg_stat_get_activity,including: 

    (..., backend_xid XID, backend_xminxid XID, ...) pg_stat_get_activity(pid INTEGER)

    (..., transactionid XID, ...) pg_lock_status()

    (transaction XID, ...) pg_prepared_xact()

    timestamptz pg_xact_commit_timestamp(XID)

    (xid XID, ...) pg_last_committed_xact()

    (..., xmin XID, catalog_xmin XID, ...) pg_get_replication_slots()

    ... more that I'm too lazy to copy-and-paste just now ...

I would expect that, eventually, these would be upgraded to xid8.  If that happened seemlessly in one release, then
therewould be no problem with some functions returning 4-byte xids and some returning 8-byte xids, but otherwise there
wouldbe a transition period where some have been reworked to return xid8 but others not, and users during that
transitionperiod might be happier with Alvaro's suggestion of treating epoch/xid as two fields in xid8in and xid8out.
I'malso doubtful that these functions would be "upgraded".  It seems far more likely that alternate versions, perhaps
namedsomething with /xid8/ in them, would exist side-by-side with the originals. 

So I'm really just wondering where others on this list think all this is heading, and if there are any arguments
brewingabout that which could be avoided by making assumptions clear right up front. 


—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company