| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur |
| Date: | 2017-05-12 13:44:12 |
| Message-ID: | 16162.1494596652@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Fri, May 12, 2017 at 1:28 PM, Tsunakawa, Takayuki
> <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
>> Likewise, when the first host has already reached max_connections, libpq doesn't attempt the connection aginst later hosts.
> It seems to me that the feature is behaving as wanted. Or in short
> attempt to connect to the next host only if a connection cannot be
> established. If there is a failure once the exchange with the server
> has begun, just consider it as a hard failure. This is an important
> property for authentication and SSL connection failures actually.
I would not really expect that reconnection would retry after arbitrary
failure cases. Should it retry for "wrong database name", for instance?
It's not hard to imagine that leading to very confusing behavior.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Neha Khatri | 2017-05-12 13:55:29 | Re: If subscription to foreign table valid ? |
| Previous Message | K S, Sandhya (Nokia - IN/Bangalore) | 2017-05-12 13:42:25 | Re: Crash observed during the start of the Postgres process |