Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

On 19 August 2016 at 21:10, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)
com> wrote:

> On 8/18/16 9:20 PM, Craig Ringer wrote:
> > On 19 August 2016 at 02:35, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com
> > <mailto:Jim(dot)Nasby(at)bluetreble(dot)com>> wrote:
> > I think we need to either add real types for handling XID/epoch/TXID
> > or finally create uint types. It's *way* too easy to screw things up
> > the way they are today.
> >
> > Hm. Large scope increase there. Especially introducing unsigned types.
> > There's a reason that hasn't been done already - it's not just copying a
> > whole pile of code, it's also defining all the signed/unsigned
> > interactions and conversions carefully.
>
> https://github.com/petere/pguint ;-)
>
> > I'm not against adding a 'bigxid' or 'epoch_xid' or something,
> > internally a uint64. It wouldn't need all the opclasses, casts, function
> > overloads, etc that uint8 would.
>
> That sounds much better.

Yeah, but not something I expect to be able to do in the near future :S .
As it is, this is considerably off what I really need to be working on. And
we'll still want a way to get the short 32-bit xid with detection of epoch
wrap, which is what this patch adds.

I posted an updated version of this patch on
https://www.postgresql.org/message-id/CAMsr+YHQiWNEi0daCTboS40T+V5s_+dst3PYv_8v2wNVH+Xx4g@mail.gmail.com
since it's stacked on top of txid_status(bigint) now. The patch there is
just a trivial rename of this one.

I don't expect to get to adding a 'bigxid' commit and converting
views/functions in this release cycle. Still too much else to do.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services