On Tue, Oct 15, 2013 at 10:34 AM, Andres Freund <andres@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
