Re: Proposal: Implement failover on libpq connect level.

On 3 September 2015 at 12:57, Shulgin, Oleksandr <
oleksandr(dot)shulgin(at)zalando(dot)de> wrote
>
> On Thu, Sep 3, 2015 at 6:02 PM, Robert Haas <robertmhaas(at)gmail(dot)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(at)favehost:5432/some_db_name --uri
postgresql://postgres(at)favehost:5432/another_db_name --uri
postgresql://postgres(at)favehost:5432/third_db_name --uri
postgresql://postgres(at)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?"