Sent from my iPad
On 28-Jul-2013, at 5:53, Marko Tiikkaja <marko@joh.to> wrote:
> Hi,
>
> Yesterday an interesting scenario was diagnosed on IRC. If you're running a synchronous slave and the connection to
theslave is lost momentarily, your backends start naturally waiting for the slave to reconnect. If then your
applicationkeeps trying to create new connections, it can use all non-reserved connections, thus locking out the
synchronousslave when the connection problem has resolved itself. This brings the entire cluster into a state where
manualintervention is necessary.
>
Solving that was fun!
> While you could limit the number of connections for non-replication roles, that's not always possible or desirable.
Iwould like to introduce a way to reserve connection slots for replication. However, it's not clear how this would
work. I looked at how superuser_reserved_connections is implented, and with small changes I could see how to implement
twoideas:
>
> 1) Reserve a portion of superuser_reserved_connections for replication
> connections. For example, with max_connections=10,
> superuser_reserved_connections=2 and
> replication_reserved_connections=1, at 8 connections either a
> replication connection or a superuser connection can be created,
> and at 9 connections only a superuser one would be allowed. This
> is a bit clumsy as there still aren't guaranteed slots for
> replication.
>
I would generally in agree with sharing super user reserved connections with replication.One thing I would like to
exploreis if we could potentially add some sort of priority system for avoiding contention between super user threads
andreplication threads competing for the same connection.
We could potentially add a GUC for specifying which has the higher priority.
I am just musing here,though.
Thanks and Regards,
Atri