Re: Proposal: Implement failover on libpq connect level. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Proposal: Implement failover on libpq connect level.
Date
Msg-id CA+Tgmobv3Ud6V2b3F1fiPsP+DM60cpwLcXwzpFLgy1dn3O652A@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  (PostgreSQL - Hans-Jürgen Schönig<postgres@cybertec.at>)
List pgsql-hackers
On Tue, Aug 18, 2015 at 6:07 AM, PostgreSQL - Hans-Jürgen Schönig
<postgres@cybertec.at> wrote:
>> On 18 Aug 2015, at 11:19, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>>
>> Hans-Jürgen Schönig wrote:
>>> in addition to that you have the “problem” of transactions. if you failover in the middle
>>> of a transaction, strange things might happen from the application point of view.
>>>
>>> the good thing, however, is that stupid middleware is sometimes not able to handle
>>> failed connections. however, overall i think it is more of a danger than a benefit.
>>
>> Maybe I misunderstood the original proposal, but my impression was that the alternative
>> servers would be tried only at the time the connection is established, and there would be no
>> such problems as you describe.
>
> it would still leave the problem of having a read only on the other side unless you are using BDR or so.

That doesn't make this a bad idea.  Some people are using replication
solutions that can cope with this already (EDB has a proprietary
product, and I'm sure there are people using BDR, too) and, as the
solutions get better and more widely deployed, more people will want
to do it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: allowing wal_level change at run time
Next
From: Robert Haas
Date:
Subject: Re: WIP: SCRAM authentication