Re: Patch for reserved connections for replication users - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Patch for reserved connections for replication users
Date
Msg-id 525C2941.5010906@agliodbs.com
Whole thread Raw
In response to Fwd: Patch for reserved connections for replication users  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Patch for reserved connections for replication users  (Andres Freund <andres@2ndquadrant.com>)
Re: Patch for reserved connections for replication users  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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"

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: dynamic shared memory
Next
From: Tom Lane
Date:
Subject: Re: Long paths for tablespace leads to uninterruptible hang in Windows