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

From Robert Haas
Subject Re: Reviewing freeze map code
Date
Msg-id CA+TgmoZ3Q3ypceH-QT4qhaVyPQACgDoUugGna2MXDw3AE6HpNQ@mail.gmail.com
Whole thread Raw
In response to Re: Reviewing freeze map code  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Reviewing freeze map code  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Reviewing freeze map code  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> Attached is a sample patch that controls full page vacuum by new GUC parameter.
>
> Don't we want a reloption for that? Just wondering...

Why?  Just for consistency?  I think the bigger question here is
whether we need to do anything at all.  It's true that, without some
new option, we'll lose the ability to forcibly vacuum every page in
the relation, even if all-frozen.  But there's not much use case for
that in the first place.  It will be potentially helpful if it turns
out that we have a bug that sets the all-frozen bit on pages that are
not, in fact, all-frozen.  Otherwise, what's the use?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Reviewing freeze map code
Next
From: Amit Kapila
Date:
Subject: Re: [sqlsmith] Failed assertion in parallel worker (ExecInitSubPlan)