On Tue, Oct 15, 2013 at 10:34 AM, Andres Freund <and...@2ndquadrant.com> wrote: >> But I also agree that making max_wal_senders act as both a minimum and >> a maximum is no good. +1 to everything Josh Berkus said. > > Josh said we should treat replication connections in a separate "pool" > from normal database connections, right? So you withdraw your earlier > objection to that?
I don't think that's what he said. Here's what I was referring to: $ Changing max_wal_senders requires a restart. As such, we currently $ advise users to set the setting generously: "as many replication $ connections as you think you'll ever need, plus two". If $ max_wal_senders is a reservation which could cause the user to run out $ of other connections sooner than expected, then the user is faced with a $ new "hard to set" parameter: they don't want to set it too high *or* too $ low. $ $ This would result in a lot of user frustration as they try to get thier $ connection configuration right and have to restart the server multiple $ times. I find few new features worth making it *harder* to configure $ PostgreSQL, and reserved replication connections certainly don't qualify. $ $ If it's worth having reserved replication connections (and I can see $ some reasons to want it), then we need a new GUC for this: $ "reserved_walsender_connections" -- 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
