From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Freezing without write I/O |
Date: | 2013-05-30 18:46:50 |
Message-ID: | CAHyXU0x3c=m+zKWdkaTfHSdungOu5M8za5roBAZDG9HkHTvoEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 30, 2013 at 1:39 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> The reason we have to freeze is that otherwise our 32-bit XIDs wrap around
>> and become ambiguous. The obvious solution is to extend XIDs to 64 bits, but
>> that would waste a lot space. The trick is to add a field to the page header
>> indicating the 'epoch' of the XID, while keeping the XIDs in tuple header
>> 32-bit wide (*).
>
> (3) You still need to periodically scan the entire relation, or else
> have a freeze map as Simon and Josh suggested.
Why is this scan required?
Also, what happens if you delete a tuple on a page when another tuple
on the same page with age > 2^32 that is still in an open transaction?
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2013-05-30 18:48:12 | Vacuum, Freeze and Analyze: the big picture |
Previous Message | Robert Haas | 2013-05-30 18:39:46 | Re: Freezing without write I/O |