Re: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: Libpq support to connect to standby server as priority
Дата
Msg-id CADK3HHJq5h7chjLPS-ZuEd=63KBihsJ8ebWHZ172z64016eNhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Ответы Re: Libpq support to connect to standby server as priority  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Список pgsql-hackers


On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii <ishii@sraoss.co.jp> wrote:
> From: Tatsuo Ishii [mailto:ishii@sraoss.co.jp]
>> But pg_is_in_recovery() returns true even for a promoting standby. So
>> you have to wait and retry to send pg_is_in_recovery() until it
>> finishes the promotion to find out it is now a primary. I am not sure
>> if backend out to be responsible for this process. If not, libpq would
>> need to handle it but I doubt it would be possible.
>
> Yes, the application needs to retry connection attempts until success.  That's not different from PgJDBC and other DBMSs.

I don't know what PgJDBC is doing, however I think libpq needs to do
more than just retrying.

1) Try to find a node on which pg_is_in_recovery() returns false. If
   found, then we assume that is the primary. We also assume that
   other nodes are standbys. done.

2) If there's no node on which pg_is_in_recovery() returns false, then
   we need to retry until we find it. To not retry forever, there
   should be a timeout counter parameter.


IIRC this is essentially what pgJDBC does.


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

Предыдущее
От: Dave Cramer
Дата:
Сообщение: Re: Libpq support to connect to standby server as priority
Следующее
От: Dave Cramer
Дата:
Сообщение: Re: Libpq support to connect to standby server as priority