Re: Patch: Implement failover on libpq connect level.

Craig Ringer <craig@2ndquadrant.com>

From: Craig Ringer <craig@2ndquadrant.com>
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-15T09:13:46Z
Lists: pgsql-hackers
On 14 October 2015 at 18:41, Victor Wagner <vitus@wagner.pp.ru> wrote:

> 5. Added new parameter readonly=boolean. If this parameter is false (the
> default) upon successful connection check is performed that backend is
> not in the recovery state. If so, connection is not considered usable
> and next host is tried.

What constitutes "failed" as far as this is concerned?

Like the PgJDBC approach I wonder how much this'll handle in practice
and how it'll go with less clear-cut failures like disk-full on a
replica that's a member of the failover pool, long delays before
no-route-to-host errors, dns problems, etc.

Had any chance to simulate network failures?

-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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.