Re: Libpq support to connect to standby server as priority
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>, 'Tom Lane' <tgl@sss.pgh.pa.us>, Dave Cramer <pg@fastcrypt.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-01-18T08:27:04Z
Lists: pgsql-hackers
Tsunakawa, Takayuki wrote: > From: Laurenz Albe [mailto:laurenz.albe@cybertec.at] > > I think that transaction_read_only is good. > > > > If it is set to false, we are sure to be on a replication primary or > > stand-alone server, which is enough to know for the load balancing use case. > > As Tatsuo-san said, setting default_transaction_read_only leads to a misjudgement of the primary. Yes, you can have a false negative, i.e. fail to recognize a primary server. > > I deem it unlikely that someone will set default_transaction_read_only to > > FALSE and then complain that the feature is not working as expected, but > > again > > I cannot prove that claim. > > I wonder what default_transaction_read_only exists for. For maing the database by default > and allowing only specific users to write to the database with "CREATE/ALTER USER SET > default_transaction_read_only = false"? I'd guess that the main use of default_transaction_read_only is to make sure an application (that isn't smart enough to change the parameter) won't modify any data. > I'm sorry to repeat myself, but anyway, I think we need a method to connect to a standby > as the original desire, because the primary instance may be read only by default while > only limited users update data. That's for reducing the burdon on the primary and > minimizing the impact on users who update data. For example, > > * run data reporting on the standby > * backup the database from the standby > * cascade replication from the standby I see. But then the new value should not be called "prefer-read", because that would be misleading. It would also not be related to the existing "read-write". For what you have in mind, there should be the options "primary-required" and "standby-preferred", however we implement them. Have there been a lot of complaints that the existing "read-write" is not good enough to detect replication primaries? > > As Robert said, transaction_read_only might even give you the option to > > use the feature for more than just load balancing between replication master > > and standby. > > What use case do you think of? If you want to load balance the workload between > the primary and standbys, we can follow PgJDBC -- targetServerType=any. One use case I can think of is logical replication (or other replication methods like Slony). You can use the feature by setting default_transaction_read_only = on on the standby. Yours, Laurenz Albe
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