Re: replication_reserved_connections - Mailing list pgsql-hackers

From Gibheer
Subject Re: replication_reserved_connections
Date
Msg-id 20130728192103.1e06d850@linse.fritz.box
Whole thread Raw
In response to replication_reserved_connections  (Marko Tiikkaja <marko@joh.to>)
Responses Re: replication_reserved_connections
List pgsql-hackers
On Sun, 28 Jul 2013 02:23:47 +0200
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 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 use all non-reserved connections, thus locking
> out the synchronous slave when the connection problem has resolved
> itself. This brings the entire cluster into a state where manual
> intervention is necessary.
> 
> 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 looked at how 
> superuser_reserved_connections is implented, and with small changes I 
> could see how to implement two ideas:
> 
>    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.
>    2) A GUC which says "superuser_reserved_connections can be used up
> by replication connections", and then limiting the number of
>       replication connections using per-role limits to make sure
>       superusers aren't locked out.
> 
> Does anyone see a better way to do this?  I'm not too satisfied with 
> either of these ideas.
> 
> 
> Regards,
> Marko Tiikkaja
> 
> 

Hi,

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

I am still waiting for feedback though.

regards,

Stefan Radomski



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Comparing toasted data (was improve Chinese locale performance)
Next
From: Greg Stark
Date:
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY