On 2013-08-02 08:16:15 -0400, Robert Haas wrote:
> 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()).
I don't think the implementation is correct, but why don't you like the
definitional change? The set of things you can do from replication
connections are completely different from a normal connection. So using
separate "pools" for them seems to make sense.
That they end up allocating similar internal data seems to be an
implementation detail to me.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
