On Mon, Jan 21, 2019 at 5:48 PM Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Haribabu Kommi [mailto:kommi.harib...@gmail.com] > > Thanks for finding out the problem, how about the following way of > checking > > for prefer-read/prefer-standby. > > > > 1. (default_transaction_read_only = true and recovery = true) > > > > 2. If none of the host satisfies the above scenario, then recovery = true > > 3. Last check is for default_transaction_read_only = true > > That would be fine. But as I mentioned in another mail, I think "get > read-only session" and "connect to standby" differ. So I find it better to > separate parameters for those request; target_session_attr and > target_server_type. > Thanks for your opinion. target_session_attrs checks for the default_transaction_readonly or not? target_server_type checks for whether the server is in recovery or not? I feel having two options make this feature complex to use it from the user point of view? The need of two options came because of a possibility of a master server with default_transaction_readonly set to true. Even if the default transaction is readonly, it is user changeable parameter, so there shouldn't be any problem. The same can be applied for logical replication also, the user can change the default transaction mode once the connection is established, if it is not according to it's requirement. how about just adding one parameter that takes the options similar like JDBC? target_server_type - Master, standby and prefer-standby. (The option names can revised based on the common words on the postgresql docs?) And one more thing, what happens when the server promotes to master but the connection requested is standby? I feel we can maintain the existing connections and later new connections can be redirected? comments? Regards, Haribabu Kommi Fujitsu Australia
