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
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 |