On Fri, Jun 3, 2016 at 1:43 PM, Andres Freund <and...@anarazel.de> wrote: >> I really don't get it. There's nothing in any set of guidelines for >> setting shared_buffers that I've ever seen which would cause people to >> avoid this scenario. > > The "roughly 1/4" of memory guideline already mostly avoids it? It's > hard to constantly re-dirty a written-back page within 30s, before the > 10% (background)/20% (foreground) limits apply; if your shared buffers > are larger than the 10%/20% limits (which only apply to *available* not > total memory btw).
I've always heard that guideline as "roughly 1/4, but not more than about 8GB" - and the number of people with more than 32GB of RAM is going to just keep going up. >> You're the first person I've ever heard describe this as a >> misconfiguration. > > Huh? People tried addressing this problem for *years* with bigger / > smaller shared buffers, but couldn't easily. I'm saying that setting 8GB of shared_buffers on a system with lotsamem is not widely regarded as misconfiguration. > I'm inclined to give up and disable backend_flush_after (not the rest), > because it's new and by far the "riskiest". But I do think it's a > disservice for the majority of our users. I think that's the right course of action. I wasn't arguing for disabling either of the other two. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
