On 2013-10-14 10:26:25 -0700, Josh Berkus wrote:
> On 10/13/2013 01:38 AM, Gibheer wrote:
> > So it will ensure that max_wal_senders is used for reserving
> >> connection slots from being used by non-super user connections. I find
> >> new usage of max_wal_senders acceptable, if anyone else thinks
> >> otherwise, please let us know.
>
> I think otherwise.
>
> 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"
Imo the complications around this prove my (way earlier) point that it'd
be much better to treat replication connections as something entirely
different to normal SQL connections. There's really not much overlap
here and while there's some philosophical point to be made about it all
being connections, from a practical POV treating them separately seems
better.
If we were designing on a green field I'd just rename max_connections to
something explicitly talking about client database connections, but
renaming it seems like it'd cause unnecessary pain.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services