| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reviewing freeze map code |
| Date: | 2016-06-06 09:34:32 |
| Message-ID: | CA+TgmoZ3Q3ypceH-QT4qhaVyPQACgDoUugGna2MXDw3AE6HpNQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jun 6, 2016 at 5:11 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2016-06-06 10:07:21 | Re: Parallel pg_dump's error reporting doesn't work worth squat |
| Previous Message | Michael Paquier | 2016-06-06 09:11:13 | Re: Reviewing freeze map code |