Re: Proposal: Implement failover on libpq connect level.

Поиск
Список
Период
Сортировка
От Shulgin, Oleksandr
Тема Re: Proposal: Implement failover on libpq connect level.
Дата
Msg-id CACACo5QDkL+ZUowjT+_ohT2jsJ=O36hj=04iT-khcR4zGe4Kmw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal: Implement failover on libpq connect level.  (''Victor Wagner *EXTERN*' *EXTERN*' *EXTERN* <vitus@wagner.pp.ru>)
Список pgsql-hackers
Дерево обсуждения
On Wed, Aug 19, 2015 at 4:45 PM, ''Victor Wagner *EXTERN*' *EXTERN*' *EXTERN* <vitus@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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Make HeapTupleSatisfiesMVCC more concurrent
Следующее
От: jacques klein
Дата:
Сообщение: how to write/setup a C trigger function in a background worker