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
signature.asc
Description: PGP signature