Re: Usage of epoch in txid_current

On 2018-07-10 10:32:44 +0800, Craig Ringer wrote:
> On 10 July 2018 at 07:35, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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