On 30 July 2015 at 15:24, Heikki Linnakangas <hlinn...@iki.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
