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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
