Re: [HACKERS] bigint vs txid user confusion - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: [HACKERS] bigint vs txid user confusion
Date
Msg-id CAMsr+YF6mLrQ8n+JCHH5aqdcYVujdBSQ=uTJuaGi5+_EZFDuxQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] bigint vs txid user confusion  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 21 December 2016 at 14:06, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 12/20/16 10:20 PM, Craig Ringer wrote:
>>
>> Tools look at pg_class.relfrozenxid and pg_databse.datfrozenxid more
>> than probably anything else, so making changes that ignores them is
>> pretty pointless.
>
>
> Except the only useful way I know of to access *frozenxid is using age(),
> and even that is a royal PITA when the xid is a special xid. So I'd argue
> that we should effectively remove xid from user's view. Even if we don't
> want to bloat pg_class by 4 bytes, we should just make xid even more opaque
> than it is today and tell users to just cast it to bigxid.

That's a good point. Keep it as 'xid' to avoid bloating pg_class.
age(...) continues to make sense there. Change everything else to
bigxid.

If we decide we need comparisons of xid >|<|= bigxid, provide a cast
of xid to bigxid that assumes the current epoch maybe. I'm not super
fond of that though, since users can still write
  XID '1234'

Unsure about how to handle that.


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



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] asynchronous execution