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

Victor Wagner wrote:
> > > Idea is that we don't need any extra administration actions such as IP
> > > migration to do it. Clients have list of alternate servers and discover
> > > which one to work with by trial and error.
> >
> > Yes, but that will only work reliably if the (read-only) standby does not
> > allow connections before it is promoted.
> 
> It would just take a bit more time for client and a bit more load for
> server - to make sure that this connection is read-write by
> issuing
> 
>     show transaction_read_only
> 
> statement before considering connection useful.

That's not very comfortable, and a lot of middleware software won't easily
learn the trick.

But even without that use case I think that the feature is probably
worth the effort.

[about having multiple "host" parameters in the connection string]

> > One problem with that is that this syntax is already allowed, but
> > your proposal would silently change the semantics.
> > Today, if you have multiple "host" parameters, the last one wins.
> > So with your modification in place, some connect strings that work today
> > would start behaving in unexpected ways.
> 
> This is serious argument. But what the use case of these connect strings
> now?
>
> It seems to me that in most cases last host in the connect string would
> be only host which accepts connections, so it wins anyway

I'm not saying that it is particularly wide-spread and useful; it could
happen through careless editing of connection strings or by using a
connection service file entry
(http://www.postgresql.org/docs/current/static/libpq-pgservice.html)
and overriding the host parameter on the command line.

> > Maybe a better idea would be:
> >   host=db1.myorg.com,db2.myorg.com port=5432,2345
> 
> I've tried not to introduce new delimiters. But this syntax definitely
> have some advantages. At least it allows to specify host-port pairs as
> two parallel lists.
> 
> Other idea - allow to specify host-port pair as argument of host
> parameter.
> 
>   host=db1.myorg.com:5432
> 
> It is consistent with URL syntax and system administrators are used to
> it. And with long list of hosts there is less chances to made an error
> as host and corresponding port come together.

I don't think that is very attactive as it confuses the distinction between
"host" and "port".  What would you do with
  host=db1.myorg.com:2345 port=1234

Yours,
Laurenz Albe