From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | 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 14:24:51 |
Message-ID: | 55BA33B3.3030507@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2015-07-30 14:32:19 | Re: 64-bit XIDs again |
Previous Message | Simon Riggs | 2015-07-30 14:14:14 | Re: 64-bit XIDs again |