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: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "laurenz.albe@cybertec.at" <laurenz.albe@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-17T13:36:06Z
Lists: pgsql-hackers 
On Tue, 15 Jan 2019 at 23:21, Tsunakawa, Takayuki <
tsunakawa.takay@jp.fujitsu.com> wrote:

> From: Dave Cramer [mailto:pg@fastcrypt.com]
> >       The original desire should have been the ability to connect to a
> > primary or a standby.  So, I think we should go back to the original
> thinking
> > (and not complicate the feature), and create a read only GUC_REPORT
> variable,
> > say, server_role, that identifies whether the server is a primary or a
> > standby.
> >
> >
> >
> > I'm confused as to how this would work. Who or what determines if the
> server
> > is a primary or standby?
>
> Overall, the server determines the server role (primary or standby) using
> the same mechanism as pg_is_in_recovery(), and set the server_role GUC
> parameter.  As the parameter is GUC_REPORT, the change is reported to the
> clients using the ParameterStatus ('S') message.  The clients also get the
> value at connection.
>

Thanks, that clarifies it.


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.