Re: 64-bit XIDs again - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: 64-bit XIDs again
Date
Msg-id 55BA33B3.3030507@iki.fi
Whole thread Raw
In response to 64-bit XIDs again  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Responses Re: 64-bit XIDs again
Re: 64-bit XIDs again
Re: 64-bit XIDs again
List 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




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: 64-bit XIDs again
Next
From: Joe Conway
Date:
Subject: Re: 64-bit XIDs again