Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nKz7K-0003sD-NT for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Feb 2022 08:59:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKz7J-0005PA-53 for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Feb 2022 08:59:53 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nKz7I-0005P1-SE for pgsql-hackers@lists.postgresql.org; Fri, 18 Feb 2022 08:59:52 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nKz7F-0002TE-Oa for pgsql-hackers@lists.postgresql.org; Fri, 18 Feb 2022 08:59:51 +0000 Received: from [192.168.11.10] (p2010165-ipbf2302funabasi.chiba.ocn.ne.jp [122.25.95.165]) by oss.nttdata.com (Postfix) with ESMTPSA id B70CE60792; Fri, 18 Feb 2022 17:59:46 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.5 at oss.nttdata.com Message-ID: Date: Fri, 18 Feb 2022 17:59:46 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [Proposal] Add foreign-server health checks infrastructure Content-Language: en-US To: "kuroda.hayato@fujitsu.com" , 'Kyotaro Horiguchi' Cc: "pgsql-hackers@lists.postgresql.org" , "Shinya11.Kato@oss.nttdata.com" , "zyu@yugabyte.com" References: <20220216.115058.1615761004338301624.horikyota.ntt@gmail.com> <20220217.171405.1911593760090019851.horikyota.ntt@gmail.com> From: Fujii Masao In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022/02/17 19:35, kuroda.hayato@fujitsu.com wrote: > Dear Horiguchi-san, > >> I think we just don't need to add the special timeout kind to the >> core. postgres_fdw can use USER_TIMEOUT and it would be suffiction to >> keep running health checking regardless of transaction state then fire >> query cancel if disconnection happens. As I said in the previous main, >> possible extra query cancel woud be safe. Sounds reasonable to me. > I finally figured out that you mentioned about user-defined timeout system. > Firstly - before posting to hackers - I designed like that, > but I was afraid of an overhead that many FDW registers timeout > and call setitimer() many times. Is it too overcautious? Isn't it a very special case where many FDWs use their own user timeouts? Could you tell me the assumption that you're thinking, especially how many FDWs are working? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION