Re: bigint vs txid user confusion

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bigint vs txid user confusion
Date: 2016-12-21 08:07:24
Message-ID: CAMsr+YF6mLrQ8n+JCHH5aqdcYVujdBSQ=uTJuaGi5+_EZFDuxQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21 December 2016 at 14:06, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro HORIGUCHI 2016-12-21 08:23:58 Re: asynchronous execution
Previous Message Craig Ringer 2016-12-21 08:02:15 Re: [PATCH] Transaction traceability - txid_status(bigint)