Re: Reviewing freeze map code

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:
>> On Fri, Jul 1, 2016 at 10:22 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> > Ah, you're right, I misunderstood.
>> >
>> > Attached updated patch incorporating your comments.
>> > I've changed it so that heap_xlog_lock clears vm flags if page is
>> > marked all frozen.
>>
>> I believe that this should be separated into two patches, since there
>> are two issues here:
>>
>> 1. Locking a tuple doesn't clear the all-frozen bit, but needs to do so.
>> 2. heap_update releases the buffer content lock without logging the
>> changes it has made.
>>
>> With respect to #1, there is no need to clear the all-visible bit,
>> only the all-frozen bit. However, that's a bit tricky given that we
>> removed PD_ALL_FROZEN. Should we think about putting that back again?
>
> I think it's fine to just do the vm lookup.
>
>> 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?

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