On Fri, 2 Aug 2013 08:16:15 -0400
Robert Haas <robertmhaas@gmail.com> 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()).
>
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
