Horton

RE: Libpq support to connect to standby server as priority

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Tatsuo Ishii' <ishii@sraoss.co.jp>
Cc: "pg@fastcrypt.com" <pg@fastcrypt.com>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, "kommi.haribabu@gmail.com" <kommi.haribabu@gmail.com>, "jingwangian@gmail.com" <jingwangian@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2019-01-16T08:26:28Z
Lists: pgsql-hackers 
From: Tatsuo Ishii [mailto:ishii@sraoss.co.jp]
> 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.

It may be convenient for libpq to be able to retry connection attempts for a specified duration (by failover_timeout or such), because it eliminates the need for the application to do the retry.  But I think it's a desirable feature, not a required one.


Regards
Takayuki Tsunakawa

Commits

  1. Make test_target_session_attrs more robust against connection failure.

  2. Extend the abilities of libpq's target_session_attrs parameter.

  3. Mark default_transaction_read_only as GUC_REPORT.

  4. Introduce a new GUC_REPORT setting "in_hot_standby".

  5. Avoid spamming the client with multiple ParameterStatus messages.

  6. Avoid harmless Valgrind no-buffer-pin errors.

  7. Restructure libpq code to remove some duplicity

  8. libpq: Add target_session_attrs parameter.