Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur
От | Stephen Frost |
---|---|
Тема | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur |
Дата | |
Msg-id | 20170517165252.GF3151@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternative hosts when some errors occur
|
Список | pgsql-hackers |
Tom, Robert, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > 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. Agreed. > 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. Right. > 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. No particular comment on this. I do wonder about forward/backwards compatibility in such lists and if SQLSTATE really covers all cases/distinctions which are interesting when it comes to making this decision. Thanks! Stephen
В списке pgsql-hackers по дате отправления: