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-16T05:41:03Z
Lists: pgsql-hackers 
From: Tatsuo Ishii [mailto:ishii@sraoss.co.jp]
> But pg_is_in_recovery() returns true even for a promoting standby. So
> you have to wait and retry to send pg_is_in_recovery() until it
> finishes the promotion to find out it is now a primary. I am not sure
> if backend out to be responsible for this process. If not, libpq would
> need to handle it but I doubt it would be possible.

Yes, the application needs to retry connection attempts until success.  That's not different from PgJDBC and other DBMSs.


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.