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+Tgmob64+A1pmLeFjvB6=TA9KZZ2gSysu3TxcC2xUvtfVzkRg@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Wed, Sep 9, 2015 at 4:30 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> I think the problem we should be trying to solve is: Given a set
>> of server IPs, connect to one that is up.
>>
>> I believe this comes up in several different scenarios.
>>
>> Example #1: [single server; changing IP address gracefully]
>>
>> Example #2: [xDB/BDR client uses local master if up; else a remote]
>>
>> Example #3: [SR/HS with changing primary]
>
> For all of those it is clear that we do not need (or want!)
> heartbeat, STONITH, fencing, etc. to be handled by the connector.
> If the above are the sorts of problems we are trying to solve, a
> very simple solution is the best.  I know you outlined several; I'm
> not sure it would matter all that much which one we used -- any
> would work and someone should Just Do It.
>
>> I'm sure there are more.
>
> Ay, there's the rub.  Some people seemed to be suggesting that this
> should be far more than what you describe above.  That would, IMO,
> be a mistake.

It sounds like we are pretty much on the same page.  :-)

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Moving SS_finalize_plan processing to the end of planning
Next
From: Anastasia Lubennikova
Date:
Subject: [PROPOSAL] Covering + unique indexes.