From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 64-bit XIDs again |
Date: | 2015-07-30 15:04:27 |
Message-ID: | CANP8+jLdHMbcdeJiqx=7rkX26vMaU2XgeR=Ga8y0mqZ8Uh93Sg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30 July 2015 at 15:24, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 07/30/2015 04:26 PM, Alexander Korotkov wrote:
>
>> Also, I think it's possible to migrate to 64-bit XIDs without breaking
>> pg_upgrade. Old tuples can be leaved with 32-bit XIDs while new tuples
>> would be created with 64-bit XIDs. We can use free bits in t_infomask2 to
>> distinguish old and new formats.
>>
>
> I think we should move to 64-bit XIDs in in-memory structs snapshots, proc
> array etc. And expand clog to handle 64-bit XIDs. But keep the xmin/xmax
> fields on heap pages at 32-bits, and add an epoch-like field to the page
> header so that logically the xmin/xmax fields on the page are 64 bits wide,
> but physically stored in 32 bits. That's possible as long as no two XIDs on
> the same page are more than 2^31 XIDs apart. So you still need to freeze
> old tuples on the page when that's about to happen, but it would make it
> possible to have more than 2^32 XID transactions in the clog. You'd never
> be forced to do anti-wraparound vacuums, you could just let the clog grow
> arbitrarily large.
>
This is a good scheme, but it assumes, as you say, that you can freeze
tuples that are more than 2^31 xids apart. That is no longer a safe
assumption on high transaction rate systems with longer lived snapshots.
> There is a big downside to expanding xmin/xmax to 64 bits: it takes space.
> More space means more memory needed for caching, more memory bandwidth,
> more I/O, etc.
My feeling is that the overhead will recede in time. Having a nice, simple
change to remove old bugs and new would help us be more robust.
But let's measure the overhead before we try to optimize it away.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2015-07-30 15:12:39 | Re: 64-bit XIDs again |
Previous Message | Heikki Linnakangas | 2015-07-30 14:59:48 | Re: 64-bit XIDs again |