Re: Automatic Client Failover - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Automatic Client Failover
Date
Msg-id 200808151825.m7FIPu820739@momjian.us
Whole thread Raw
In response to Re: Automatic Client Failover  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Automatic Client Failover  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> > > Implementation would be to make PQreset() try secondary connection if
> > > the primary one fails to reset. Of course you can program this manually,
> > > but the feature is that you wouldn't need to, nor would you need to
> > > request changes to 27 different interfaces either.
> > 
> > I assumed share/pg_service.conf would help in this regard;  place the
> > file on a central server and modify that so everyone connects to another
> > server. Perhaps we could even add round-robin functionality to that.
> 
> I do want to keep it as simple as possible, but we do need a way that
> will work without reconfiguration at the time of danger. It needs to be
> preconfigured and tested, then change controlled so we all know it
> works.

OK, so using share/pg_service.conf as an implementation example, how
would this work?  The application supplies multiple service names and
libpq tries attaching to each one in the list until one works?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Hannu Krosing
Date:
Subject: Re: proposal sql: labeled function params
Next
From: Hannu Krosing
Date:
Subject: Re: proposal sql: labeled function params