Prev: psql: edit function, show function commandspatch
Next: [HACKERS] Alias to rollback keyword
From: Robert Haas on 31 Mar 2010 21:52
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>> That's an interesting point, do streaming replication connections
>> consume superuser_reserved_connections slots?
>
> Yes. Since SR connection is superuser connection, setting
> superuser_reserved_connections appropriately would be useful
> to prevent non-superuser connections from blocking the connection
> from the standby.

I think this is wacky, especially since we'd someday like to have
replication be a separate privilege from superuser. I think we should
change this.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 31 Mar 2010 22:00
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
> On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>>>> That's an interesting point, do streaming replication connections
>>>> consume superuser_reserved_connections slots?
>>>
>>> Yes. Since SR connection is superuser connection, setting
>>> superuser_reserved_connections appropriately would be useful
>>> to prevent non-superuser connections from blocking the connection
>>> from the standby.
>>
>> I think this is wacky, especially since we'd someday like to have
>> replication be a separate privilege from superuser.  I think we should
>> change this.
>
> You mean that we should change replication connection not to consume
> superuser_reserved_connections slots in 9.0?

Yes.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 1 Apr 2010 13:18
On Thu, Apr 1, 2010 at 9:09 AM, Heikki Linnakangas
<heikki.linnakangas(a)enterprisedb.com> wrote:
> Fujii Masao wrote:
>> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas <robertmhaas(a)gmail.com> wrote:
>>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>>>> You mean that we should change replication connection not to consume
>>>> superuser_reserved_connections slots in 9.0?
>>> Yes.
>
> I think it's good that walsenders can use the superuser reserved slots,
> that way a client that opens max_connections connections can't block out
> standby servers from connecting.
>
>> Preventing superuser connections from consuming superuser_reserved_connections
>> slots seems strange for me. So I'm leaning toward just removing superuser
>> privilege from replication connection again. Thought?
>
> That would be good, but I fear it's a bigger change than we should be
> doing at this point.
>
> How about we adjust the backends math a bit:
>
> Currently:
>
> ReservedBackends = superuser_reserved_connections
> MaxBackends = max_connections + autovacuum_max_workers + 1;
>
> Proposal:
>
> ReservedBackends = superuser_reserved_connections + max_wal_senders
> MaxBackends = max_connections + autovacuum_max_workers + max_wal_senders + 1
>
> So we implicitly reserve a slot and a superuser reserved slot for each
> walsender. Walsenders use the slots reserved for superusers, but if you
> set superuser_reserved_connections=3, there's still always at least
> three slots available for superuser to log in with psql, even if the
> maximum number of walsenders are connected.

That seems pretty reasonable to me. I haven't checked how much code
impact there is. I know Tom doesn't think we should change it at all,
but surely pre-beta is the time to fix nasty corner cases that were
added by recently committed patches?

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Kevin Grittner" on 1 Apr 2010 13:44
Tom Lane <tgl(a)sss.pgh.pa.us> wrote:

> Having replication connections use superuser reserved slots seems
> exactly the behavior I'd expect given that they are running as
> superuser.

It seems within the realm of possibility that not all users would
think to boost superuser_reserved_connections by the number of
replication connections, and be surprised when they are unable to
connect in an emergency.

-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 1 Apr 2010 13:58
On Thu, Apr 1, 2010 at 1:46 PM, Josh Berkus <josh(a)agliodbs.com> wrote:
> On 4/1/10 10:44 AM, Kevin Grittner wrote:
>> It seems within the realm of possibility that not all users would
>> think to boost superuser_reserved_connections by the number of
>> replication connections, and be surprised when they are unable to
>> connect in an emergency.
>
> Well, that's easy to add to the documentation.

It's probably also easy to fix so that it doesn't NEED to be documented.

The thing is, when dealing with new features, we reduce our overall
maintenance burden if we get it right the first time. Obviously it's
too late for major changes, but minor adjustments to maintain the POLA
seem like exactly what we SHOULD be doing right now.

....Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3
Prev: psql: edit function, show function commandspatch
Next: [HACKERS] Alias to rollback keyword