Re: Freezing without write I/O - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Freezing without write I/O
Date
Msg-id CAHyXU0x3c=m+zKWdkaTfHSdungOu5M8za5roBAZDG9HkHTvoEw@mail.gmail.com
Whole thread Raw
In response to Re: Freezing without write I/O  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Freezing without write I/O  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Thu, May 30, 2013 at 1:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, May 30, 2013 at 9:33 AM, Heikki Linnakangas
> <hlinnakangas@vmware.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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Freezing without write I/O
Next
From: Josh Berkus
Date:
Subject: Vacuum, Freeze and Analyze: the big picture