Re: Proposal: Implement failover on libpq connect level.

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.

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.

Alternatively, change the rules for parsing the existing host=X
> parameter so that we split it on some separator that isn't a valid
> hostname character, and then strip off an optional :port syntax from
> each entry; that value, if present, overrides port=X for that entry.
>

It's tempting to use ':' as the separator here, but it's still valid for
directory names and host can be one in case of UN*X sockets.

--
Alex