Re: Reviewing freeze map code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reviewing freeze map code
Date
Msg-id 5402.1465221188@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reviewing freeze map code  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Reviewing freeze map code  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> On Sat, Jun 4, 2016 at 1:46 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> 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.

I find this approach fairly ugly ... it's randomly inconsistent with other
VACUUM parameters for no very defensible reason.  Taking out GUCs is not
easier than taking out statement parameters; you risk breaking
applications either way.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: OUT parameter and RETURN table/setof
Next
From: Merlin Moncure
Date:
Subject: Re: Relax requirement for INTO with SELECT in pl/pgsql