Re: Proposal: Implement failover on libpq connect level.

On Wed, Aug 19, 2015 at 4:45 PM, ''Victor Wagner *EXTERN*' *EXTERN*'
*EXTERN* <vitus(at)wagner(dot)pp(dot)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