Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur |
Дата | |
Msg-id | CAB7nPqTo_vi-66rDmzUT4dCcAjVP7K-XsdPxUTuA0VJXFmbX3w@mail.gmail.com обсуждение исходный текст |
Ответ на | 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
Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur |
Список | pgsql-hackers |
On Thu, May 18, 2017 at 11:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, May 18, 2017 at 7:06 AM, Michael Paquier > <michael.paquier@gmail.com> wrote: >> FWIW, I am of the opinion to not have an implementation based on any >> SQLSTATE codes, as well as not doing something similar to JDBC. >> Keeping things simple is one reason, a second is that the approach >> taken by libpq is correct at its root. > > Because why? Because it is critical to let the user know as well *why* an error happened. Imagine that this feature is used with multiple nodes, all primaries. If a DB admin busted the credentials in one of them then all the load would be redirected on the other nodes, without knowing what is actually causing the error. Then the node where the credentials have been changed would just run idle, and the application would be unaware of that. -- Michael
В списке pgsql-hackers по дате отправления: