On Mon, Jun 5, 2017 at 2:38 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote: > On 06/05/2017 11:49 AM, Tianzhou Chen wrote: >> >> Hi Pg Hackers, >> >> XID wraparound seems to be quite a big concern and we introduce >> changes like “adding another frozen bit to each page” >> [http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html >> <http://rhaas.blogspot.com/2016/03/no-more-full-table-vacuums.html> >> to tackle this. I am just wondering what’s the challenges preventing >> us from moving to 64 bit xid? This is the previous thread I find >> >> https://www.postgresql.org/message-id/CAEYLb_UfC%2BHZ4RAP7XuoFZr%2B2_ktQmS9xqcQgE-rNf5UCqEt5A%40mail.gmail.com >> >> <https://www.postgresql.org/message-id/caeylb_ufc+hz4rap7xuofzr+2_ktqms9xqcqge-rnf5ucqe...@mail.gmail.com>, >> the only answer there is: >> >> “ The most obvious reason for not using 64-bit xid values is that >> they require more storage than 32-bit values. There is a patch >> floating around that makes it safe to not forcibly safety shutdown >> the server where currently it is necessary, but it doesn't work by >> making xids 64-bit. >> " >> >> I am personally not quite convinced that is the main reason, since I >> feel for database hitting this issue, the schema is mostly >> non-trivial and doesn’t matter so much with 8 more bytes. Could some >> postgres experts share more insights about the challenges? > > > That quote is accurate. We don't want to just expand XIDs to 64 bits, > because it would significantly bloat the tuple header. PostgreSQL's > per-tuple overhead is already quite large, compared to many other systems. > > The most promising approach to tackle this is to switch to 64-bit XIDs in > in-memory structures, and add some kind of an extra epoch field to the page > header. That would effectively give you 64-bit XIDs, but would only add one > a field to each page, not every tuple. >
What happens when the epoch is so low that the rest of the XID does not fit in 32bits of tuple header? Or such a case should never arise? -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
