On Thu, May 18, 2017 at 8:11 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, May 18, 2017 at 11:30 PM, Robert Haas <robertmh...@gmail.com> wrote: >> On Thu, May 18, 2017 at 7:06 AM, Michael Paquier >> <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
