On 2018-07-10 10:32:44 +0800, Craig Ringer wrote: > On 10 July 2018 at 07:35, Thomas Munro <thomas.mu...@enterprisedb.com> > wrote: > > > > > I played around with this idea yesterday. Experiment-grade patch > > attached. Approach: > > > > 1. Introduce a new type BigTransactionId (better names welcome). > > > > txid_current() should be changed to BigTransactionId too. It's currently > bigint.
That's quite a bit more work though, no? We'd have to introduce a new SQL level type (including operators). As I said nearby, I think that's a good idea, but I don't see any sort of benefit of forcing those patches to be done at once. > Users are currently left in a real mess when it comes to pg_stat_activity > xids, etc, which are epoch-unqualified. txid_current() reports an > epoch-qualified xid, but there's no sensible and safe conversion from > txid_current()'s bigint to an epoch-qualified ID. I am confused what you mean by "to an epoch-qualified ID". You want to split txid_current()'s return value into epoch and xid? Isn't that fairly trivial? SELECT bigxid & x'ffffff'::int8 AS xid, bigxid >> 32 epoch FROM txid_current() bigxid; Now I'm not saying that's pretty and couldn't be made easier. Greetings, Andres Freund
