From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(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-17 16:48:05 |
Message-ID: | 28000.1495039685@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Yeah, you have a point. I'm willing to admit that we may have defined
> the behavior of the feature incorrectly, provided that you're willing
> to admit that you're proposing a definition change, not just a bug
> fix.
> Anybody else want to weigh in with an opinion here?
I'm not really on board with "try each server until you find one where
this dbname+username+password combination works". That's just a recipe
for trouble, especially the password angle.
I think it's a good point that there are certain server responses that
we should take as equivalent to "server down", but by the same token
there are responses that we should not take that way.
I suggest that we need to conditionalize the decision based on what
SQLSTATE is reported. Not sure offhand if it's better to have a whitelist
of SQLSTATEs that allow failing over to the next server, or a blacklist of
SQLSTATEs that don't.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2017-05-17 16:51:14 | 10beta1 sequence regression failure on sparc64 |
Previous Message | Alvaro Herrera | 2017-05-17 16:44:29 | Re: [COMMITTERS] pgsql: Preventive maintenance in advance of pgindent run. |