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”
>> 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
>> 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?
The Postgres Database Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: