On Wed, Aug 19, 2015 at 12:21 PM, Victor Wagner *EXTERN* <vi...@wagner.pp.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
