Re: Patch: Implement failover on libpq connect level.

On 30 October 2015 at 09:26, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Thu, Oct 29, 2015 at 8:29 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> > On 10/28/15 4:18 AM, Victor Wagner wrote:
> >> On Mon, 26 Oct 2015 16:25:57 -0400
> >> Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> >>
> >>> Also, this assumes that all the components other than host and port
> >>> are the same. Earlier there was a discussion about why the ports
> >>> would ever need to be different. Well, why can't the database names
> >>> be different? I could have use for that.
> >>
> >> Because of way postgresql replication is implemented.
> >
> > There are multiple types of PostgreSQL replication, and there will be
> > others in the future.
>
> That's true, but doesn't allowing every parameter to be multiply
> specified greatly increase the implementation complexity for a pretty
> marginal benefit? I think host and IP would hit 98% of the use cases
> here.

I think it makes the feature WORSE. I am getting more and more convinced
that the Correct Solution is for this feature to be handled by submitting
multiple URIs, and my argument isn't even based on any aspects of
implementation complexity.

Take as example the case where I have two database servers I want to
be considered.

a) Database with URI
postgresql://cbbrowne(at)server-a(dot)example(dot)info:5432/my-first-database

b) Database with URL
postgresql://robert(at)server-b(dot)example(dot)info:7032/my-second-database

With all the "per-variable multiplicities", this would turn into a
combinatorial explosion of combinations, some 2^4, or 16 possible servers,
some of which likely don't exist, and others of which aren't proper (e.g. -
trying to connect to database a) using robert's credentials).

Possibly some of those combinations are outright improper.

I'm not going to claim it's terribly wise to be doing the cross-credential
bit; I'd think it likely to be rather dumb for the application to use one
user when connecting to one database and another when connecting to
another. But the notion of it being nondeterministic is just awful.

I head back to... "the way OpenLDAP does this"...
They let you specify multiple LDAP servers...
ldap://server1.example.info:389 ldap://server2.example.info:389
where URIs are separated by whitespace.

Seems like Best Goodness for Postgres to do something analogous...
postgresql://cbbrowne(at)server-a(dot)example(dot)info:5432/my-first-database
postgresql://robert(at)server-b(dot)example(dot)info:7032/my-second-database

Is it a bit long? Sure. But it is unambiguous, and requires *only*
whitespace parsing to separate the URIs. I'd think it fine for Postgres to
support this via multiple "-d" options; that would be about as good.

That can cover 100% of cases, and I don't see it needing to interact
specially with odd bits such as "was that a replication slot?" You can
always choose to shoot yourself in the foot, but this doesn't spin the
roulette for you...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"