From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Gurjeet Singh <gurjeet(at)singh(dot)im>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz> |
Subject: | Re: 64-bit XIDs again |
Date: | 2015-07-31 06:32:46 |
Message-ID: | 55BB168E.3080101@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/31/2015 09:22 AM, Gurjeet Singh wrote:
> On Jul 30, 2015 2:23 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But the elephant in the room is on-disk compatibility. There is
>> absolutely no way that we can just change xmin/xmax to 64 bits without a
>> disk format break. However, if we do something like what Heikki is
>> suggesting, it's at least conceivable that we could convert incrementally
>> (ie, if you find a page with the old header format, assume all tuples in
>> it are part of epoch 0; and do not insert new tuples into it unless there
>> is room to convert the header to new format ... but I'm not sure what we
>> do about tuple deletion if the old page is totally full and we need to
>> write an xmax that's past 4G).
>
> Can we safely relegate the responsibility of tracking the per block epoch
> to a relation fork?
Sounds complicated and fragile. I would rather attack the page version
problem head on.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2015-07-31 06:45:19 | Re: Updatable view? |
Previous Message | Tatsuo Ishii | 2015-07-31 06:29:31 | Re: Updatable view? |