From: | Tianzhou Chen <tianzhouchen(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Challenges preventing us moving to 64 bit transaction id (XID)? |
Date: | 2017-06-05 08:49:34 |
Message-ID: | DA1E65A4-7C5A-461D-B211-2AD5F9A6F2FD@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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-rNf5UCqEt5A@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?
Thanks
Tianzhou
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-06-05 09:08:05 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |
Previous Message | Etsuro Fujita | 2017-06-05 08:45:51 | Update comments in nodeModifyTable.c |