Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ff4qf-0006M4-Nw for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jul 2018 14:51:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ff4qd-0004aA-TH for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jul 2018 14:51:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ff4qd-0004a3-Bg for pgsql-hackers@lists.postgresql.org; Mon, 16 Jul 2018 14:51:35 +0000 Received: from mx2.mailbox.org ([80.241.60.215]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1ff4qV-0001pn-V8 for pgsql-hackers@postgresql.org; Mon, 16 Jul 2018 14:51:33 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx2.mailbox.org (Postfix) with ESMTPS id 23226414D2; Mon, 16 Jul 2018 16:42:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter01.heinlein-hosting.de (spamfilter01.heinlein-hosting.de [80.241.56.115]) (amavisd-new, port 10030) with ESMTP id IIiITVs_gcV6; Mon, 16 Jul 2018 16:42:25 +0200 (CEST) Message-ID: <1531752143.2534.60.camel@cybertec.at> Subject: Re: Libpq support to connect to standby server as priority From: Laurenz Albe To: Haribabu Kommi Cc: Jing Wang , Pg Hackers , "Tsunakawa, Takayuki" Date: Mon, 16 Jul 2018 16:42:23 +0200 In-Reply-To: References: <1530710078.2411.29.camel@cybertec.at> Organization: Cybertec Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Haribabu Kommi wrote: > > On Wed, Jul 4, 2018 at 11:14 PM Laurenz Albe 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