On Tue, Jan 15, 2019 at 02:00:57AM +0000, Tsunakawa, Takayuki wrote: > But as some people said, I don't think this is the right way. I > suppose what's leading to the current somewhat complicated situation > is that there was no easy way for the client to know whether the > server is the master. That ended up in using "SHOW > transaction_read_only" instead, and people supported that compromise > by saying "read only status is more useful than whether the server > is standby or not," I'm afraid.
Right. Another pin point is that it is complicated for a client to be sure that it is connected to a standby as at the time between transaction_read_only is checked and the connection is reported as ready to be used for the application, you may be actually linked to a primary which has just recently been promoted. I am not personally sure if it is worth caring about that in such level of details to get to get something useful, but there have been doubts about not making that absolutely right to leverage correctly applications willing to use read-only clients. > The original desire should have been the ability to connect to a > primary or a standby. So, I think we should go back to the original > thinking (and not complicate the feature), and create a read only > GUC_REPORT variable, say, server_role, that identifies whether the > server is a primary or a standby. From the point of view of making sure that a client is really connected to a primary or a standby, this is the best idea around. -- Michael
signature.asc
Description: PGP signature
