On Mon, Jun 6, 2016 at 5:44 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada.m...@gmail.com> wrote:
>> On Sat, Jun 4, 2016 at 12:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Fri, Jun 3, 2016 at 11:21 AM, Masahiko Sawada <sawada.m...@gmail.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...

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to