Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur |
Дата | |
Msg-id | CA+Tgmoa1MfnBsSE9-z1p2JTdsKRfjWcrVP=mLTHYVR8ToRo-Aw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [bug fix] PG10: libpq doesn't connect to alternativehosts when some errors occur (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Thu, May 18, 2017 at 8:11 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > 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. The entire purpose of an application-level failover feature is to make the application unaware of failures. That's like complaining that the stove gets hot when you turn it on. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: