Re: Libpq support to connect to standby server as priority
Greg Nancarrow <gregn4422@gmail.com>
From: Greg Nancarrow <gregn4422@gmail.com>
To: vignesh C <vignesh21@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
Peter Smith <smithpb2250@gmail.com>, "Smith, Peter" <peters@fast.au.fujitsu.com>,
David Steele <david@pgmasters.net>, "Tsunakawa, Takayuki" <tsunakawa.takay@fujitsu.com>,
Haribabu Kommi <kommi.haribabu@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, Dave Cramer <pg@fastcrypt.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Elvis Pranskevichus <elprans@gmail.com>
Date: 2021-02-09T00:17:14Z
Lists: pgsql-hackers
On Mon, Feb 8, 2021 at 8:17 PM vignesh C <vignesh21@gmail.com> wrote:
>
> >
> > I think what we want to do is mark default_transaction_read_only as
> > GUC_REPORT, instead. That will give a reliable report of what the
> > state of its GUC is, and you can combine it with is_hot_standby
> > to decide whether the session should be considered read-only.
> > If you don't get those two GUC values during connection, then you
> > can fall back on "SHOW transaction_read_only".
> >
>
> I have made a patch for the above with the changes suggested and
> rebased it with the head code.
> Attached v21 patch which has the changes for the same.
> Thoughts?
>
I'm still looking at the patch code, but I noticed that the
documentation update describing how support of read-write transactions
is determined isn't quite right and it isn't clear how the parameters
work.
I'd suggest something like the following (you'd need to fix the line
lengths and line-wrapping appropriately) - please check it for
correctness:
<para>
The support of read-write transactions is determined by the value of the
<varname>default_transaction_read_only</varname> and
<varname>in_hot_standby</varname> configuration parameters,
that, if supported,
are reported by the server upon successful connection. If the
value of either
of these parameters is <literal>on</literal>, it means the
server doesn't support
read-write transactions. If either/both of these parameters
are not reported,
then the support of read-write transactions is determined by
an explicit query,
by sending <literal>SHOW transaction_read_only</literal> after
successful
connection; if it returns <literal>on</literal>, it means the
server doesn't
support read-write transactions. The standby mode state is
determined by either
the value of the <varname>in_hot_standby</varname> configuration
parameter, that is reported by the server (if supported) upon
successful connection, or is otherwise explicitly queried by sending
<literal>SELECT pg_is_in_recovery()</literal> after successful
connection; if it returns <literal>t</literal>, it means the server is
in hot standby mode.
</para>
Regards,
Greg Nancarrow
Fujitsu Australia
Commits
-
Make test_target_session_attrs more robust against connection failure.
- 3769e11a3183 14.0 landed
-
Extend the abilities of libpq's target_session_attrs parameter.
- ee28cacf619f 14.0 landed
-
Mark default_transaction_read_only as GUC_REPORT.
- d16f8c8e416d 14.0 landed
-
Introduce a new GUC_REPORT setting "in_hot_standby".
- bf8a662c9afa 14.0 landed
-
Avoid spamming the client with multiple ParameterStatus messages.
- 2432b1a04087 14.0 landed
-
Avoid harmless Valgrind no-buffer-pin errors.
- a766d6ca22ac 14.0 cited
-
Restructure libpq code to remove some duplicity
- b438e7e7a1c5 13.0 landed
-
libpq: Add target_session_attrs parameter.
- 721f7bd3cbcc 10.0 cited