Re: Patch for reserved connections for replication users

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Gibheer <gibheer(at)zero-knowledge(dot)org>, 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-15 03:52:15
Message-ID: CAA4eK1Jz6R4S8L+mP_kbWHxEvOuB68CcWLzx1YK8t3SerjKAOA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 14, 2013 at 10:56 PM, Josh Berkus <josh(at)agliodbs(dot)com> 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.

It is documented in the patch that configuration max_wal_senders is
reserved from max_connections.
So it will not cause the user to run out of other connections sooner
than expected, if both the variables are configured properly.

> 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"

Having new variable also might make users life difficult, as with new
variable he needs to take care of setting 3 parameters
(max_wal_senders, reserved_walsender_connections, max_connections)
appropriately for this purpose and then choosing value for
reserved_walsender_connections will be another thing for which he has
to consult.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2013-10-15 04:13:53 Re: Patch for reserved connections for replication users
Previous Message KONDO Mitsumasa 2013-10-15 01:00:26 Re: Compression of full-page-writes