On Wed, Aug 19, 2015 at 4:45 PM, ''Victor Wagner *EXTERN*' *EXTERN*' *EXTERN* <vi...@wagner.pp.ru> wrote:
> On 2015.08.19 at 15:35:17 +0100, Simon Riggs wrote: > > > > > I think we do need some way of saying that a readonly connection is OK. > So > > I had such thing in my propsal (boolean parameter readonly). > But haven't yet checked if it is compatible with jdbc syntax. > > > the default would be to connect to each in turn until we find the master. > > It should keep retrying for a period of time since for a short period it > is > > possible there is no master. If you specify readonly, then a connection > to > > It is very important addition - to specify that if no host is able to > establish read-write session, we should retry and give a chance for > sever administration to promote one of standbys to master. Probably > there should be additional timeout parameter (we have > connection_timeout, and this would be failover_timeout) with some > reasonaable default. > Are we going to put support for every existing and new jdbc feature into libpq? One day they might want to add another parameter, e.g. the number of retries before failing ultimately (hm, and probably, delay between retries). Should we already prepare for that? I believe a good library should provide all the building blocks instead of trying to envision every possible use case and incorporate them as convenience functions. All the described above can be implemented in terms of existing libpq features rather easily. Not to mention that the proposed approach doesn't scale really well, IMO: once you have incorporated all your database hosts in client's connection string, you need additional steps to maintain this list on the app configuration side. And the fact that a lot of other db connector libraries do this in one or the other way, isn't actually an argument in favor of the feature, at least not for me. -- Alex
