Re: Libpq support to connect to standby server as priority
Haribabu Kommi <kommi.haribabu@gmail.com>
From: Haribabu Kommi <kommi.haribabu@gmail.com>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, Tom Lane <tgl@sss.pgh.pa.us>, Dave Cramer <pg@fastcrypt.com>, Robert Haas <robertmhaas@gmail.com>, Jing Wang <jingwangian@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-03-19T01:33:39Z
Lists: pgsql-hackers
On Thu, Feb 28, 2019 at 1:00 PM Tsunakawa, Takayuki < tsunakawa.takay@jp.fujitsu.com> wrote: > From: Haribabu Kommi [mailto:kommi.haribabu@gmail.com] > > Attached are the updated patches. > > Thanks, all look fixed. > > > > The target_server_type option yet to be implemented. > > Please let me review once more and proceed to testing when the above is > added, to make sure the final code looks good. I'd like to see how complex > the if conditions in multiple places would be after adding > target_server_type, and consider whether we can simplify them together with > you. Even now, the if conditions seem complicated to me... that's probably > due to the existence of read_write_host_index. > Yes, if checks are little bit complex because of additional checks to identify, I will check if there is any easier way to update them without introducing code duplication. While working on implementation of target_server_type new connection option for the libpq to specify master, slave and etc, there is no problem when the newly added target_server_type option is used separate, but when it is combined with the existing target_session_attrs, there may be some combinations that are not valid or such servers doesn't exist. Target_session_attrs Target_server_type read-write prefer-slave, slave prefer-read master, slave read-only master, prefer-slave I know that some of the cases above is possible, like master server with by default accepts read-only sessions. Instead of we put a check to validate what is right combination, how about allowing the combinations and in case if such combination is not possible, means there shouldn't be any server the supports the requirement, and connection fails. comments? And also as we need to support the new option to connect to servers < 12 also, this option sends the command "select pg_is_in_recovery()" to the server to find out whether the server is recovery mode or not? And also regarding the implementation point of view, the new target_server_type option validation is separately handled, means the check for the required server is handled in a separate switch case, when both options are given, first find out the required server for target_session_attrs and validate the same again with target_server_type? Regards, Haribabu Kommi 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