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()). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
