RE: Libpq support to connect to standby server as priority

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, even the primary is read-only.  That's why the syntax target_session_attrs = {read-write | read-only} was introduced instead of 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 during the database server failover.  I think that will be convenient, but not mandatory for this patch.  PgJDBC doesn't provide it, either.


Regards
Takayuki Tsunakawa