On Sun, Jul 28, 2013 at 2:50 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2013-07-28 02:23:47 +0200, Marko Tiikkaja wrote:
While you could limit the number of connections for non-replication roles,
that's not always possible or desirable. I would like to introduce a way to
reserve
Sent from my iPad
On 28-Jul-2013, at 5:53, Marko Tiikkaja ma...@joh.to wrote:
Hi,
Yesterday an interesting scenario was diagnosed on IRC. If you're running a
synchronous slave and the connection to the slave is lost momentarily, your
backends start naturally waiting for the slave to
On 28/07/2013 08:51, Atri Sharma wrote:
I would generally in agree with sharing super user reserved connections with
replication.One thing I would like to explore is if we could potentially add
some sort of priority system for avoiding contention between super user threads
and replication
On Sun, 28 Jul 2013 02:23:47 +0200
Marko Tiikkaja ma...@joh.to wrote:
Hi,
Yesterday an interesting scenario was diagnosed on IRC. If you're
running a synchronous slave and the connection to the slave is lost
momentarily, your backends start naturally waiting for the slave to
reconnect.
On 2013-07-28 19:21, Gibheer wrote:
I had the same problem and I created a patch to introduce a GUC for
reserved_replication_connections as a seperate flag.
You can find my patch here
https://commitfest.postgresql.org/action/patch_view?id=1180
Oops. I guess I should've searched through the
On 2013-07-28 02:23:47 +0200, Marko Tiikkaja wrote:
While you could limit the number of connections for non-replication roles,
that's not always possible or desirable. I would like to introduce a way to
reserve connection slots for replication. However, it's not clear how this
would work. I
Hi,
Yesterday an interesting scenario was diagnosed on IRC. If you're
running a synchronous slave and the connection to the slave is lost
momentarily, your backends start naturally waiting for the slave to
reconnect. If then your application keeps trying to create new
connections, it can
