On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier <michael@paquier.xyz> wrote:
> On Wed, Apr 18, 2018 at 10:52:51AM -0400, Robert Haas wrote:
>> I would just document the risks. If the documentation says that you
>> can't rely on the value until after the next checkpoint, or whatever
>> the rule is, then I think we're fine. I don't think that we really
>> have the infrastructure to do any better; if we try, we'll just end up
>> with odd warts. Documenting the current set of warts is less churn
>> and less work.
>
> The last version of the patch proposed has eaten this diff which was
> part of one of the past versions (v2-0001-Change-FPW-handling.patch from
> https://www.postgresql.org/message-id/20180412.103430.133595350.horiguchi.kyotaro%40lab.ntt.co.jp):
> + The default is <literal>on</literal>. The change of the parameter takes
> + effect at the next checkpoint time.
> So there were some documentation about the beHavior change for what it's
> worth.
>
> And, er, actually, I was thinking again about the case where a user
> wants to disable full_page_writes temporarily to do some bulk load and
> then re-enable it. With the patch proposed to actually update the FPW
> effect at checkpoint time, then a user would need to issue a manual
> checkpoint after updating the configuration and reloading, which may
> create more I/O than he'd want to pay for, then a second checkpoint
> would need to be issued after the configuration comes back again.
>
Why a second checkpoint? One checkpoint either manual or automatic
should be enough to make the setting effective.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com