On Mon, Oct 14, 2013 at 11:21 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> 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.
If we think this way, then may be we should have max_user_connections
instead of max_connections and then max_wal_connections. But still
there are other's like pg_basebackup who needs connections and
tomorrow there can be new such entities which need connection.
Also we might need to have different infrastructure in code to make
these options available to users.
I think having different parameters to configure maximum connections
for different entities can complicate both code as well as user's job.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com