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

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid
Date: 2016-08-18 09:34:53
Message-ID: CAMsr+YEnVLo6CDkDAdOB3eWLFampE3rbZ2hpK3aQrq2axZ5CUQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 16 August 2016 at 21:44, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:

> On 16 August 2016 at 20:58, Greg Stark <stark(at)mit(dot)edu> wrote:
>
>> On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer <craig(at)2ndquadrant(dot)com>
>> wrote:
>> > I'm surprised the 32-bit xid was ever exposed to the user, rather than a
>> > 64-bit epoch-extended xid.
>>
>> Once upon a time we didn't have epoch counting at all.
>>
>
> Makes sense. I didn't dig back too far in history.
>
> Sounds like you're in favour of the 2nd part of the proposal (not covered
> by the current patch) then.
>
> I haven't yet done the validation required on the epoch logic btw, and I
> won't be too surprised if it's a bit off. I'm writing a fast xid burn
> function for use in testing now. I doubt it'll be fast enough to use in
> routine regression testing since all those clog pages will still take time.
> But we'll see. I'd kind of like to be able to avoid all that - advance the
> xid counter and treat all the old xids as frozen. I don't know or if this
> is practical within a normal backend though.
>
> Anyway, will follow up with more tests and - probably - a bugfix or three
> soon.
>

I've written a function to fast-forward the xid counter efficiently, so I
can reach xid wraparound in 5s or so. Probably not quite fast enough to be
desirable in the basic 'make check' but close. Coming soon.

In the process I noticed that even in the regression tests there are
mistakes with xid handling, like

where virtualtransaction = (
select virtualtransaction
from pg_locks
where transactionid = txid_current()::integer)

which breaks if txid_current() returns anything > INT32_MAX.

To do it right(ish) you have to

where virtualtransaction = (
select virtualtransaction
from pg_locks
where transactionid::text::bigint = (txid_current() & (BIGINT '1'
<< 32)) )

... I think.

So yeah, we need a function to get the 'xid' component from an xid with
epoch and/or to fix up things that expose 'xid' to expose bigint txids. The
patch on the start of this mail is the first step.

--
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 Emre Hasegeli 2016-08-18 10:26:55 Re: regexp_match() returning text
Previous Message Stephen Frost 2016-08-18 09:20:51 Re: patch proposal