Haribabu Kommi wrote: > > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe <laurenz.a...@cybertec.at> > > wrote: > > > Haribabu Kommi wrote: > > > > > > - I think the construction with "read_write_host_index" makes the code > > > even more > > > complicated than it already is. > > > > > > What about keeping the first successful connection open and storing it > > > in a > > > variable if we are in "prefer-read" mode. > > > If we get the read-only connection we desire, close that cached > > > connection, > > > otherwise use it. > > > > Even if we add a variable to cache the connection, I don't think the logic > > of checking > > the next host for the read-only host logic may not change, but the extra > > connection > > request to the read-write host again will be removed. > > I evaluated your suggestion of caching the connection and reuse it when there > is no > read only server doesn't find, but I am thinking that it will add more > complexity and also > the connection to the other servers delays, the cached connection may be > closed by > the server also because of timeout. > > I feel the extra time during connection may be fine, if user is preferring > the prefer-read > mode, instead of adding more complexity in handling the cached connection? > > comments?
I tested the new patch, and it works as expected. I don't think that time-out of the cached session is a valid concern, because that would have to be a really short timeout. On the other hand, establishing the connection twice (first to check if it is read-only, then again because no read-only connection is found) can be quite costly. But that is a matter of debate, as is the readability of the code. Since I don't think I can contribute more to this patch, I'll mark it as ready for committer. Yours, Laurenz Albe
