On Fri, 2 Aug 2013 08:16:15 -0400 Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Jul 30, 2013 at 3:10 AM, Gibheer <gibh...@zero-knowledge.org> > wrote: > > here is an update off my patch based on the discussion with Marko > > Tiikkaja and Andres Freund. > > > > Marko and I had the idea of introducing reserved connections based > > on roles as it would create a way to garantuee specific roles to > > connect when other roles use up all connections for whatever > > reason. But Andreas said, that it would make connecting take much > > too long. > > > > So to just fix the issue at hand, we decided that adding > > max_wal_senders to the pool of reserved connections is better. With > > that, we are sure that streaming replication can connect to the > > master. > > > > So instead of creating a new configuration option I added > > max_wal_senders to the reserved connections and changed the check > > for new connections. > > > > The test.pl is a small script to test, if the patch does what it > > should. > > Hmm. It seems like this match is making MaxConnections no longer mean > the maximum number of connections, but rather the maximum number of > non-replication connections. I don't think I support that > definitional change, and I'm kinda surprised if this is sufficient to > implement it anyway (e.g. see InitProcGlobal()). > You are right, that can't be correct. The slots I added with max_wal_sender would end up as background worker slots. I have to check my tests again. In my first patch I just copied the part to limit the connections based on superuser reserved connections + replication reserved connections. That did not change the definition of max_connections and made superuser connections higher in priority than replication connections. Is that the better approach? Thank you for your input. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
