On Tue, Apr 20, 2010 at 7:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Current logic says we hit the connection limit if:
if (!am_superuser
ReservedBackends 0
!HaveNFreeProcs(ReservedBackends))
Couldn't we
Robert Haas robertmh...@gmail.com 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
On Wed, Apr 21, 2010 at 12:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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
On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas robertmh...@gmail.com 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
On Tue, Apr 20, 2010 at 5:47 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Apr 20, 2010 at 11:04 AM, Robert Haas robertmh...@gmail.com wrote:
Instead of doing this, could we just change the logic in InitPostgres?
Current logic says we hit the connection limit if:
if
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com 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.
On Tue, Apr 20, 2010 at 9:40 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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*
On Tue, Apr 20, 2010 at 7:52 PM, Robert Haas robertmh...@gmail.com 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
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao masao.fu...@gmail.com 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 =
Robert Haas robertmh...@gmail.com writes:
On Tue, Apr 20, 2010 at 9:47 AM, Fujii Masao masao.fu...@gmail.com 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:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Fujii Masao masao.fu...@gmail.com 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:
Robert Haas robertmh...@gmail.com 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)
On Tue, Apr 20, 2010 at 11:01 PM, Robert Haas robertmh...@gmail.com 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
On Fri, Apr 2, 2010 at 2:06 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Apr 2, 2010 at 2:58 AM, Robert Haas robertmh...@gmail.com 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
Fujii Masao wrote:
On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
You mean that we should change replication connection not to consume
superuser_reserved_connections slots in 9.0?
Yes.
I
Heikki Linnakangas heikki.linnakan...@enterprisedb.com 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?
On Thu, Apr 1, 2010 at 9:09 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
You mean that we should change
Robert Haas robertmh...@gmail.com 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
Tom Lane t...@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
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
On Thu, Apr 1, 2010 at 1:46 PM, Josh Berkus j...@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
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 a
Josh Berkus j...@agliodbs.com 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
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 what we
Fujii Masao wrote:
***
*** 829,834 if (!triggered)
--- 826,834
para
Set the maximum number of concurrent connections from the standby
servers
(see xref linkend=guc-max-wal-senders for details).
+Since those connections are for
On Thu, Apr 1, 2010 at 5:39 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Fujii Masao wrote:
***
*** 829,834 if (!triggered)
--- 826,834
para
Set the maximum number of concurrent connections from the standby
servers
(see
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao masao.fu...@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
On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao masao.fu...@gmail.com wrote:
That's an interesting point, do streaming replication connections
consume superuser_reserved_connections slots?
Yes. Since SR connection is
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao masao.fu...@gmail.com wrote:
That's an interesting point, do streaming replication connections
On Thu, Apr 1, 2010 at 11:00 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:58 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Apr 1, 2010 at 10:52 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 31, 2010 at 9:50 PM, Fujii Masao masao.fu...@gmail.com wrote:
33 matches
Mail list logo
