Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur
Date
Msg-id 28000.1495039685@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur  (Stephen Frost <sfrost@snowman.net>)
Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.
Next
From: Christoph Berg
Date:
Subject: [HACKERS] 10beta1 sequence regression failure on sparc64