Re: Proposal: Implement failover on libpq connect level.

On Wed, Aug 19, 2015 at 12:21 PM, Victor Wagner *EXTERN* <vitus(at)wagner(dot)pp(dot)ru>
wrote:
>
> On 2015.08.18 at 08:32:28 +0000, Albe Laurenz wrote:
>
> > I wonder how useful this is at the present time.
> >
> > If the primary goes down and the client gets connected to the standby,
> > it would have read-only access there. Most applications wouldn't cope
> > well with that.
>
> It is supposed that somebody (either system administrator or some
> cluster management software) have noticed failure of master and promoted
> one of the standbys to master.
>
> So, clients have only to find out which cluster node serves as master
> just now.
>
> Idea is that we don't need any extra administration actions such as IP
> migration to do it. Clients have list of alternate servers and discover
> which one to work with by trial and error.
>
> I consider in my proposal following situations:
>
> 1. Warm standby - doesn't accept client connection at all unless
> promoted to master.
>
> 2. Hot standby - we have two types of clients - one for which readonly
> access is sufficient, and other that need to connect only to master.
> In this case intention to write is explicitely stated in the connect
> string (readonly=false) and connect procedure would check if node it
> tries to connect allowed write.
>
> It seems that most people discussing in this thread think in millisecond
> time intervals (failure and immediate reconnect).

Why not have this as a separate parameter (*_timeout or something like
that)?

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com