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
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 landed
-
Remove superuser checks in pgstattuple
- fd321a1dfd64 10.0 cited
-
Fix unwanted flushing of libpq's input buffer when socket EOF is seen.
- c405918858c0 9.6.0 cited