From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Gibheer <gibheer(at)zero-knowledge(dot)org> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, marko(at)joh(dot)to, Mike Blackwell <maiku41(at)gmail(dot)com> |
Subject: | Re: Patch for reserved connections for replication users |
Date: | 2013-10-14 17:26:25 |
Message-ID: | 525C2941.5010906@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-10-14 17:30:09 | Re: Long paths for tablespace leads to uninterruptible hang in Windows |
Previous Message | Robert Haas | 2013-10-14 15:50:44 | Re: dynamic shared memory |