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

From Christopher Browne
Subject Re: Proposal: Implement failover on libpq connect level.
Date
Msg-id CAFNqd5UVXsLcqxA2pjY+0V0Btek34h1EwxVofND+Z-_+BUUTgQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal: Implement failover on libpq connect level.  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
List pgsql-hackers
On 3 September 2015 at 12:57, Shulgin, Oleksandr <oleksandr.shulgin@zalando.de> wrote
>
> On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>>
>> Maybe someday we should have all that, but I think for right now
>> that's complicating things unnecessarily.  I think the best proposal
>> so far is to allow the host=X option to be repeated multiple times.
>> If you repeat the host=X option N times, you can also repeat the
>> port=X option exactly N times, or else you can specify it just once.
>> Done.
>
>
> But this already breaks backwards-compatibility with any clients who belief that whatever value specified the latest takes precedence.  I'm not arguing that there are such use cases in the wild or that it's entirely sane thing to do, but still.
>
> More importantly, this will break any code that tries to parse the conninfo string and produce a hashmap from it for modification.

The notion of an "ordered hashmap" makes me break out in hives...

>> Alternatively, leave the host=X option alone and add a new option
>> hostlist=X, allowing a comma-separated list of names or IPs, with each
>> hostname or IP allowed an optional :port suffix.  If host=X parameter
>> is omitted or the connection to that machine fails, try everybody in
>> the hostlist concurrently, or with some configurable (and presumably
>> short) delay between one and then next.  Again, done.
>
>
> The exact behavior in case of both host/port and hostlist are specified becomes really tricky then.  It's already tricky enough, if you recall the service files -- how are they going to come into play here?
>
> I believe the less there are implicit workings in the way libpq connects, the better.

In that case, let's have a New Option, and expressly break with the implicit bits.

The new option ONLY accepts URIs, but allows it to be submitted multiple times.

psql --uri postgresql://postgres@favehost:5432/some_db_name --uri postgresql://postgres@favehost:5432/another_db_name --uri postgresql://postgres@favehost:5432/third_db_name --uri postgresql://postgres@favehost:5432/fourth_backup_db

Parsing conninfo strings is no fun.  I'm finding I prefer using URIs.  They may even be easier to parse, not that I have thus far cared; using URIs tends to mean I don't *need* to parse anything.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Proposal: Implement failover on libpq connect level.
Next
From: Stephen Frost
Date:
Subject: Re: Proposal: Implement failover on libpq connect level.