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

<div dir="ltr">On 30 October 2015 at 09:26, Robert Haas <<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>>wrote:<br />><br />> On Thu, Oct 29, 2015 at
8:29PM, Peter Eisentraut <<a href="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> wrote:<br />> > On 10/28/15
4:18AM, Victor Wagner wrote:<br />> >> On Mon, 26 Oct 2015 16:25:57 -0400<br />> >> Peter Eisentraut
<<ahref="mailto:peter_e@gmx.net">peter_e@gmx.net</a>> wrote:<br />> >><br />> >>> Also, this
assumesthat all the components other than host and port<br />> >>> are the same.  Earlier there was a
discussionabout why the ports<br />> >>> would ever need to be different.  Well, why can't the database
names<br/>> >>> be different? I could have use for that.<br />> >><br />> >> Because of
waypostgresql replication is implemented.<br />> ><br />> > There are multiple types of PostgreSQL
replication,and there will be<br />> > others in the future.<br />><br />> That's true, but doesn't
allowingevery parameter to be multiply<br />> specified greatly increase the implementation complexity for a
pretty<br/>> marginal benefit?  I think host and IP would hit 98% of the use cases<br />> here.<br /><br />I
thinkit makes the feature WORSE.  I am getting more and more convinced<br />that the Correct Solution is for this
featureto be handled by submitting<br />multiple URIs, and my argument isn't even based on any aspects of<br
/>implementationcomplexity.<br /><br />Take as example the case where I have two database servers I want to<br />be
considered.<br/><br />a) Database with URI<br />   postgresql://<a
href="http://cbbrowne@server-a.example.info:5432/my-first-database">cbbrowne@server-a.example.info:5432/my-first-database</a><br
/><br/>b) Database with URL<br />   postgresql://<a
href="http://robert@server-b.example.info:7032/my-second-database">robert@server-b.example.info:7032/my-second-database</a><br
/><br/>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
connectto database a) using robert's credentials).<br /><br />Possibly some of those combinations are outright
improper.<br/><br />I'm not going to claim it's terribly wise to be doing the cross-credential bit; I'd think it likely
tobe 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.<br /><br />I head back to... "the way OpenLDAP does
this"...<br/>  They let you specify multiple LDAP servers...<br />    ldap://<a
href="http://server1.example.info:389">server1.example.info:389</a>ldap://<a
href="http://server2.example.info:389">server2.example.info:389</a><br/>where URIs are separated by whitespace.<br
/><br/>Seems like Best Goodness for Postgres to do something analogous...<br />   postgresql://<a
href="http://cbbrowne@server-a.example.info:5432/my-first-database">cbbrowne@server-a.example.info:5432/my-first-database</a>
postgresql://<a
href="http://robert@server-b.example.info:7032/my-second-database">robert@server-b.example.info:7032/my-second-database</a><br
/><br/>Is it a bit long?  Sure.  But it is unambiguous, and requires *only* whitespace parsing to separate the URIs. 
I'dthink it fine for Postgres to support this via multiple "-d" options; that would be about as good.<br /><br />That
cancover 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...<br />--<br
/>Whenconfronted by a difficult problem, solve it by reducing it to the<br />question, "How would the Lone Ranger
handlethis?"</div>