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
$ 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:
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: