Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
От | Michael Banck |
---|---|
Тема | Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement |
Дата | |
Msg-id | 1491852302.25270.65.camel@credativ.de обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [pgsql-advocacy] Assembling "top features" list for betaannouncement
|
Список | pgsql-advocacy |
Am Montag, den 10.04.2017, 11:42 -0400 schrieb Peter Eisentraut: > On 4/8/17 04:50, Michael Banck wrote: > > "Client-Side Connection-Failover" > > I don't think the libpq feature can be considered "failover". Hrm. > It just picks from a list of end points on the initial connection > attempt. Right. > It does not discover connection failures and reconnect. Does any other 3rd party tooling for Postgres do that? I assume the client will get the connection failure and, upon reconnection, will get a good new connection, essentially failing over to the next host. Oracle has "Transparent Application Failover", but that's a pretty high bar I am not sure anybody is expecting us to jump over just now. I phrased it "connection-based client-side failover" in another mail, would emphasizing that it is at connection granularity be enough to address your concerns? The pgJDBC called the (AFAICT) identical feature "connection failover" in their changelogs for 9.3-1100 and 9.4-1200: https://jdbc.postgresql.org/documentation/changelog.html#version_9.3-1100 https://jdbc.postgresql.org/documentation/changelog.html#version_9.4-1200 Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.banck@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
В списке pgsql-advocacy по дате отправления: