Re: Reviewing freeze map code

On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>>>>> Can you submit that part as a separate patch?
>>>>
>>>> Attached.
>>>
>>> Thanks, committed.
>>>
>>>>>> I'm address the review comment of 7087166 commit, and will post the patch.
>>>>>
>>>>> When?
>>>>
>>>> On Saturday.
>>>
>>> Great. Will that address everything for this open item, then?
>>>
>>
>> Attached patch for commit 7087166 on another mail.
>> I think that only the test tool for visibility map is remaining and
>> under the discussion.
>> Even if we have verification tool or function for visibility map, we
>> cannot repair the contents of visibility map if we turned out that
>> contents of visibility map is something wrong.
>> So I think we should have the way that re-generates the visibility map.
>> For this purpose, doing vacuum while ignoring visibility map by a new
>> option or new function is one idea.
>> But IMHO, it's not good idea to allow a function to do vacuum, and
>> expanding the VACUUM syntax might be somewhat overkill.
>>
>> So other idea is to have GUC parameter, vacuum_even_frozen_page for example.
>> If this parameter is set true (false by default), we do vacuum whole
>> table forcibly and re-generate visibility map.
>> The advantage of this idea is that we don't necessary to expand VACUUM
>> syntax and relatively easily can remove this parameter if it's not
>> necessary anymore.
>>
>
> Attached is a sample patch that controls full page vacuum by new GUC parameter.

Don't we want a reloption for that? Just wondering...
--
Michael