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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur
Дата
Msg-id 28000.1495039685@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur  (Robert Haas <robertmhaas@gmail.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Preventive maintenance in advanceof pgindent run.
Следующее
От: Christoph Berg
Дата:
Сообщение: [HACKERS] 10beta1 sequence regression failure on sparc64