Re: Proposal: Implement failover on libpq connect level.

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Victor Wagner <vitus@wagner.pp.ru>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2015-08-20T03:06:31Z
Lists: pgsql-hackers
On Wed, Aug 19, 2015 at 1:23 PM, Victor Wagner <vitus@wagner.pp.ru> wrote:
>
> On 2015.08.19 at 12:55:15 +0530, Amit Kapila wrote:
>
> > > I think that failover procedure should begin before first connection
is
> > > ever established.
> > >
> >
> > As far as I understand, failover gets initiated once the master server
goes
> > down or is not accessible due to some reason, so for such cases if you
> > have the connection to both the servers then it might not work.
>
> Master server might go down when client is not started yet.
> And when client starts up, it has to find out which server to connect
> now.
>

Always try with the first server specified in connection string and if that
is not available try with second and so on.  I think for the case of
failover,
the design shouldn't be much complicated and it is a standard thing provided
by most of the client-side drivers in other databases.  Considering what
currently PostgreSQL offers in terms of high-availability functionality, for
load-balancing, we need to be careful of many more things like redirecting
read-queries to standby's, write statements should be executed via
connection
to master.


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

Commits

  1. libpq: Add target_session_attrs parameter.

  2. Remove superuser checks in pgstattuple

  3. Fix unwanted flushing of libpq's input buffer when socket EOF is seen.