Re: Reviewing freeze map code

On Mon, Jul 4, 2016 at 2:31 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Sat, Jul 2, 2016 at 12:17 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Sat, Jul 2, 2016 at 12:53 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>> On 2016-07-01 15:18:39 -0400, Robert Haas wrote:
>>>
>>>> Should we just clear all-visible and call it good enough?
>>>
>>> Given that we need to do that in heap_lock_tuple, which entirely
>>> preserves all-visible (but shouldn't preserve all-frozen), ISTM we
>>> better find something that doesn't invalidate all-visible.
>>>
>>
>> Sounds logical, considering that we have a way to set all-frozen and
>> vacuum does that as well. So probably either we need to have a new
>> API or add a new parameter to visibilitymap_clear() to indicate the
>> same. If we want to go that route, isn't it better to have
>> PD_ALL_FROZEN as well?
>>
>
> Cant' we call visibilitymap_set with all-visible but not all-frozen
> bits instead of clearing flags?
>

That doesn't sound to be an impressive way to deal. First,
visibilitymap_set logs the action itself which will generate two WAL
records (one for visibility map and another for lock tuple). Second,
it doesn't look consistent to me.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com