From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Problem while setting the fpw with SIGHUP |
Date: | 2018-04-13 03:01:02 |
Message-ID: | CAA4eK1LVFpLf=d-7XmfwhLv7Xu53pU0bGU=wVrYWSRU4XSsyHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 13, 2018 at 6:59 AM, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Thu, Apr 12, 2018 at 02:55:53PM -0400, Robert Haas wrote:
>> I think it may actually be confusing. If you run pg_ctl reload and it
>> reports that the value has changed, you'll expect it to have taken
>> effect. But really, it will take effect at some later time.
>
+1. I also think it is confusing and it could be difficult for end
users to know when the setting is effective.
> It is true that sometimes some people like to temporarily disable
> full_page_writes particularly when doing some bulk load of data to
> minimize the effort on WAL, and then re-enable it just after doing
> the inserting this data.
>
> Still does it matter when the change is effective? By disabling
> full_page_writes even temporarily, you accept the fact that this
> instance would not be safe until the next checkpoint completes. The
> instance even finishes by writing less unnecessary WAL data if the
> change is only effective at the next checkpoint. Well, it is true that
> this increases potential torn pages problems but the user is already
> accepting that risk if a crash happens until the next checkpoint then it
> exposes itself to torn pages anyway as it chose to disable
> full_page_writes.
>
I think this means that is will be difficult for end users to predict
unless they track the next checkpoint which isn't too bad, but won't
be convenient either.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2018-04-13 03:03:18 | Re: [HACKERS] path toward faster partition pruning |
Previous Message | David Rowley | 2018-04-13 02:41:32 | Re: Instability in partition_prune test? |