Robert Haas writes:
> ...shouldn't we move the "tests", plural, rather than just the one?
> It seems right to reject new SR connections during shutdown.
Yeah; you'd also need to adjust both of them to consider am_walsender.
(IOW, we want to treat SR connections as non-superuser for both tests.)
On Wed, Apr 21, 2010 at 12:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> Thanks for the heads up. It doesn't look hard to put a similar test
>> in the walsender code path, but is there any reason to duplicate the
>> code? Seems like we might be able to just put this test (with the
>> necessar
Robert Haas writes:
> Thanks for the heads up. It doesn't look hard to put a similar test
> in the walsender code path, but is there any reason to duplicate the
> code? Seems like we might be able to just put this test (with the
> necessary modification) right before this comment:
Hm, actually
On Tue, Apr 20, 2010 at 7:53 PM, Tom Lane wrote:
> Robert Haas writes:
>> Current logic says we hit the connection limit if:
>
>> if (!am_superuser &&
>> ReservedBackends > 0 &&
>> !HaveNFreeProcs(ReservedBackends))
>
>> Couldn't we just change this to:
>
>
On Tue, Apr 20, 2010 at 11:01 PM, Robert Haas wrote:
>> 3. Your proposal
>> Treat superuser replication connection like non-superuser one
>
> Well, only for this one very specific purpose. I would adjust the
> docs like this:
>
> Determines the number of connection "slots" that are reserved fo
Robert Haas writes:
> Current logic says we hit the connection limit if:
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBackends))
> Couldn't we just change this to:
> if ((!am_superuser || am_walsender) &&
>
Tom Lane wrote:
> Robert Haas writes:
>> Fujii Masao wrote:
>>> 3. Your proposal
>>>Treat superuser replication connection like non-superuser one
>
>> Well, only for this one very specific purpose. I would adjust
>> the docs like this:
>
>> Determines the number of connection "slots" that
Robert Haas writes:
> On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao wrote:
>> 3. Your proposal
>> Treat superuser replication connection like non-superuser one
> Well, only for this one very specific purpose. I would adjust the
> docs like this:
> Determines the number of connection "slots"
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao wrote:
> Yeah, I agree with you, but the difference is only how to achieve.
> ISTM that there are three choices:
>
> 1. Heikki's proposal
>> ReservedBackends = superuser_reserved_connections + max_wal_senders
>> MaxBackends = max_connections + autovacuu
On Tue, Apr 20, 2010 at 7:52 PM, Robert Haas wrote:
> Let's just stop for a second and think about why we have
> superuser_reserved_connections in the first place. As I understand
> it, the point is that we want to make sure that superusers don't get
> locked out of the database, because superuse
On Tue, Apr 20, 2010 at 9:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> If replication connections can use up superuser_reserved_connections
>> slots, then it's very possible that this safety valve will fail
>> completely.
>
> Only if replication can use up *all* the superuser_reserved_connecti
Robert Haas writes:
> If replication connections can use up superuser_reserved_connections
> slots, then it's very possible that this safety valve will fail
> completely.
Only if replication can use up *all* the superuser_reserved_connections
slots.
regards, tom lane
--
Robert Haas wrote:
> I don't care whether or not the replication connection is or is
> not technically a superuser connection. What I think is important
> is trying to preserve the ability for a superuser to log in
> interactively and clean up the mess even when the regular supply
> of connect
On Tue, Apr 20, 2010 at 5:47 AM, Fujii Masao wrote:
> On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
>> Instead of doing this, could we just change the logic in InitPostgres?
>>
>> Current logic says we hit the connection limit if:
>>
>> if (!am_superuser &&
>> Reserve
On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas wrote:
> Instead of doing this, could we just change the logic in InitPostgres?
>
> Current logic says we hit the connection limit if:
>
> if (!am_superuser &&
> ReservedBackends > 0 &&
> !HaveNFreeProcs(ReservedBac
On Fri, Apr 2, 2010 at 2:06 AM, Fujii Masao wrote:
> On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas wrote:
>> 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 th
On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas wrote:
> 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
On Thu, 2010-04-01 at 11:49 -0700, Josh Berkus wrote:
> > 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 wh
Josh Berkus writes:
> Oh, I agree. Since we have a separate WALSender limit, it seems
> counter-intuitive and difficult-to-admin to have the WALSenders also
> limited by superuser_connections. They should be their own separate
> connection pool, just like the other "background" processes.
+1
R
> 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.
Oh, I agree. Since we have
On Thu, Apr 1, 2010 at 1:46 PM, Josh Berkus 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
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
Tom Lane 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
rep
Robert Haas writes:
> 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?
What nasty corner case?
On Thu, Apr 1, 2010 at 9:09 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote:
>>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote:
You mean that we should change replication connection not to consume
superuser_reserved_connecti
Heikki Linnakangas writes:
> Fujii Masao wrote:
>> 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 f
Fujii Masao wrote:
> On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote:
>> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao 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
On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas wrote:
> On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote:
>> On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote:
>>> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote:
> That's an interesting point, do streaming replication connections
>
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao wrote:
> On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote:
>> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote:
That's an interesting point, do streaming replication connections
consume superuser_reserved_connections slots?
>>>
>>> Yes.
On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas wrote:
> On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao wrote:
>>> That's an interesting point, do streaming replication connections
>>> consume superuser_reserved_connections slots?
>>
>> Yes. Since SR connection is superuser connection, setting
>> supe
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao 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
> t
On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>> ***
>> *** 829,834 if (!triggered)
>> --- 826,834
>>
>> Set the maximum number of concurrent connections from the standby
>> servers
>> (see for details).
>> +
Fujii Masao wrote:
> ***
> *** 829,834 if (!triggered)
> --- 826,834
>
> Set the maximum number of concurrent connections from the standby
> servers
> (see for details).
> +Since those connections are for superusers,
> + should be
>
33 matches
Mail list logo
