From: Haribabu Kommi [mailto:kommi.haribabu@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
