On Thu, Apr 19, 2018 at 7:19 AM, Michael Paquier <mich...@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
