On 2015.08.19 at 07:15:30 +0000, Albe Laurenz 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.
>
> And as Robert said, there are people out using BDR or other proprietary
> multi-master solutions, so there might well be an audience for this feature.
Unfortunately I have no experience with such solutions, so I'd greatly
appreciate feedback from those people.
I've modelled my proposal after another proprietary solution - Oracle
RAC.
> 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
> 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.
But your variant allows to handle hostaddr parameter same way as host
and port.
-- Victor Wagner <vitus@wagner.pp.ru>
