On 08/10/2015 11:17 AM, Andres Freund wrote:
> On 2015-08-10 07:26:29 +0100, Simon Riggs wrote:
>> On 10 August 2015 at 07:14, Peter Geoghegan <pg@heroku.com> wrote:
>>
>>> On Sun, Aug 9, 2015 at 11:03 PM, Simon Riggs <simon@2ndquadrant.com>
>>> wrote:
>>>> If 5) fails to bring a workable solution by the Jan 2016 CF then we
>>> commit
>>>> 2) instead.
>>>
>>> Is there actually a conflict there? I didn't think so.
>>>
>>
>> I didn't explain myself fully, thank you for asking.
>>
>> Having a freeze map would be wholly unnecessary if we don't ever need to
>> freeze whole tables again. Freezing would still be needed on individual
>> blocks where an old row has been updated or deleted; a freeze map would not
>> help there either.
>>
>> So there is no conflict, but options 2) and 3) are completely redundant if
>> we go for 5). After investigation, I now think 5) is achievable in 9.6, but
>> if I am wrong for whatever reason, we have 2) as a backstop.
>
> I don't think that's true. You can't ever delete the clog without
> freezing. There's no need for anti-wraparound scans anymore, but you
> still need to freeze once.
What's your definition of freezing? As long as you remove all dead
tuples, you can just leave the rest in place with their original
XID+epoch in place, and assume that everything old enough is committed.
- Heikki
