RE: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: Libpq support to connect to standby server as priority
Дата
Msg-id OSAPR01MB5073A42A6540FB1861CFB35EFE2A0@OSAPR01MB5073.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Libpq support to connect to standby server as priority  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
From: Alvaro Herrera <alvherre@2ndquadrant.com>
> I'm not sure I understand why we end up with "prefer-read" in addition
> to "prefer-standby" (and similar seeming redundancy between "primary"
> and "read-write").  Do we really need more than one way to identify
> hosts' roles?  It seems 0001 adds the "prefer-read" modes by checking
> transaction_read_only, and later 0002 adds the "prefer-standby" modes by
> checking in_recovery.  I'm not sure that we're serving our users very
> well by giving them choice that ends up being confusing.  In other words
> I think we should do only one of these things, not both.  Maybe merge
> 0001 and 0002 in a single patch, and get rid of redundant modes.

That's because the distinction read/write is different from primary/standby.  If default_transaction_read_only is on,
eventhe primary is read-only.  That's why the syntax target_session_attrs = {read-write | read-only} was introduced
insteadof target_server_type = {primary | standby}.  Personally, I only want target_server_type = {primary | standby |
prefer-standby},and discard target_session_attrs for simplicity of the functional specification and the code.
 


> Also, Ishii-san said:
> https://postgr.es/m/20190116.150236.2304777214520289427.t-ishii@sraoss.c
> o.jp
>   - When looking for a primary, find a node where pg_is_in_recovery is
>     false; if none, libpq should retry until a timeout expires.  Did we
>     reject this idea altogether, or is it just unimplemented?

I don't remember well, but I guess this is for eliminating the need for applications to retry connection attempts
duringthe database server failover.  I think that will be convenient, but not mandatory for this patch.  PgJDBC doesn't
provideit, either.
 


Regards
Takayuki Tsunakawa



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Superuser can permit passwordless connections on postgres_fdw
Следующее
От: Nikita Glukhov
Дата:
Сообщение: Re: Avoid full GIN index scan when possible