| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Patch: Implement failover on libpq connect level. |
| Date: | 2015-10-15 09:13:46 |
| Message-ID: | CAMsr+YFVRizPnWwi2pszWAvD-T7iqdzaG=1-kVoYOH6S77+DWw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
On 14 October 2015 at 18:41, Victor Wagner <vitus(at)wagner(dot)pp(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shulgin, Oleksandr | 2015-10-15 09:16:01 | Re: On-demand running query plans using auto_explain and signals |
| Previous Message | Craig Ringer | 2015-10-15 09:05:33 | Re: PATCH: 9.5 replication origins fix for logical decoding |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Victor Wagner | 2015-10-15 09:43:21 | Re: Patch: Implement failover on libpq connect level. |
| Previous Message | Thomas Kellerer | 2015-10-15 09:10:34 | Re: Release 1204 released |