From: Alvaro Herrera <[email protected]>
> 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/[email protected]
> 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
