On 30.05.2013 21:46, Merlin Moncure wrote:
> 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?
To find all the dead tuples and remove them, and advance relfrozenxid.
That in turn is required so that you can truncate the clog. This scheme
relies on assuming that everything older than relfrozenxid committed, so
if there are any aborted XIDs present in the table, you can't advance
relfrozenxid past them.
Come to think of it, if there are no aborted XIDs in a range of XIDs,
only commits, then you could just advance relfrozenxid past that range
and truncate away the clog, without scanning the table. But that's quite
a special case - generally there would be at least a few aborted XIDs -
so it's probably not worth adding any special code to take advantage of
that.
> 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?
Can't let that happen. Same as today.
- Heikki
