On 2/1/17 10:27 AM, Robert Haas wrote:
On Tue, Jan 31, 2017 at 5:07 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
On 11/29/16 9:58 AM, Jeff Janes wrote:
        Considering a single SSD can do 70% of that limit, I would say

    Next question becomes... should there even be an upper limit?

Where the contortions needed to prevent calculation overflow become

I'm not a big fan of nannyism in general, but the limits on this
parameter seem particularly pointless.  You can't write out more buffers
than exist in the dirty state, nor more than implied
by bgwriter_lru_multiplier.  So what is really the worse that can happen
if you make it too high?

Attached is a patch that ups the limit to INT_MAX / 2, which is the same as

This looks fine to me.

If someone wants to proactively commit this, the CF entry is https://commitfest.postgresql.org/13/979/. (BTW, the Jan. CF is still showing as in-progress...)
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to