Horton

Re: Libpq support to connect to standby server as priority

Dave Cramer <pg@fastcrypt.com>

View thread View on postgr.es
From: Dave Cramer <pg@fastcrypt.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Tatsuo Ishii <ishii@sraoss.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-18T00:28:30Z
Lists: pgsql-hackers 
On Thu, 17 Jan 2019 at 19:09, Tsunakawa, Takayuki <
tsunakawa.takay@jp.fujitsu.com> wrote:

> From: Dave Cramer [mailto:pg@fastcrypt.com]
> >       >> 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.
>
> > Checking the code I see we actually use show transaction_read_only.
>
> Also, does PgJDBC really repeat connection attempts for a user-specified
> duration?  Having a quick look at the code, it seemed to try each host once
> in a while loop.
>

You are correct looking at the code again. On the initial connection
attempt we only try once.


Dave Cramer

davec@postgresintl.com
www.postgresintl.com

>
>

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.