On Tue, Jul 30, 2013 at 3:10 AM, Gibheer <gibheer@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