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. That
would cause a regression which could surprise a class of users. WAL and
FPW overhead is a problem which shows up a lot when doing bulk-loading
of data.
--
Michael
