On 2015.08.19 at 08:28:32 +0530, Amit Kapila wrote: > On Tue, Aug 18, 2015 at 9:48 AM, Victor Wagner <vi...@wagner.pp.ru> wrote: > > > > > > Behavoir > > -------- > > > > If PQconnectdb encounters connect string with multiple hosts specified, > > it attempts to establish connection with all these hosts simultaneously, > > and begins to work with server which responds first, unless > > loadbalancing parameter is true. > > > > > I think here you are mixing the behaviour for load balancing solution and > failover solution. It seems to me that for client-side failover solution > (which is also known as Transparent Application Failover), the connection > attempt to second server should be done after the first connection is > broken as that provide more flexibility.
I think that failover procedure should begin before first connection is ever established. When client application starts, it has no way of knowing current state of the server cluster - which of servers is working as master now. Application uses connect string, placed into its configuration file long time ago, and changing this configuration might require special permissions, user of application doesn't have. But user typically know how to restart application or reboot his terminal. So, for the spatially distributed networks with thick clients we can handle only initial connections, not connection resets. At least application author always can implement restoration of connection as closing old connection and establishing new. So, when application first establishes connection it have to be prepared to connect any of alternate hosts. I don't think that making connections in sequential order provide big flexibility. But it can greatly increase startup time, because connect to host which is physically down fails after significant timeout. While application waits for first connect to fail, it might complete session initialization with working server several times. Of course, connecting to servers in sequential order is simpler to implement, and allows even more mixing of load balancing with failover, because code would be same. > Although both ideas (load balancing and failover) seems worth discussing, > they are separate features and can be worked on separately. It will be > easier to sort out the details as well that way. Really load balancing comes almost for free if we implement connect to alternate server for failover purposes. I'm not sure that in case of hot standby, where only readonly transactions can be loadbalanced, loadbalancing is very useful. And included it in the proposal only because it is very cheap to implement in this form, > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers