RE: Libpq support to connect to standby server as priority

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)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