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 1nEuVn-0002Y7-7G for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Feb 2022 14:52:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nEuVl-0001Ab-I0 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Feb 2022 14:52:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEuVl-0001AS-8j for pgsql-hackers@lists.postgresql.org; Tue, 01 Feb 2022 14:52:01 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nEuVj-0001vp-1F for pgsql-hackers@lists.postgresql.org; Tue, 01 Feb 2022 14:52:00 +0000 Received: from [192.168.11.9] (p2019072-ipbf2307funabasi.chiba.ocn.ne.jp [122.30.130.72]) by oss.nttdata.com (Postfix) with ESMTPSA id 2BC6161019; Tue, 1 Feb 2022 23:51:55 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.5 at oss.nttdata.com Message-ID: Date: Tue, 1 Feb 2022 23:51:54 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [Proposal] Add foreign-server health checks infrastructure Content-Language: en-US To: "kuroda.hayato@fujitsu.com" Cc: "pgsql-hackers@lists.postgresql.org" , 'Shinya Kato' , "zyu@yugabyte.com" References: <4e64bb8a0a88f5b6ac5a8901377c81af@oss.nttdata.com> <0e9ea094-67df-487c-96f5-f9eabb5357c7@oss.nttdata.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/01 13:37, kuroda.hayato@fujitsu.com wrote: > Dear Fujii-san, > > Thank you for reviewing! I attached the latest version. Thanks! > Indeed and it should be avoided. I added a counter to CheckingRemoteServersCallbackItem. > The register function returns the registered item, and it must be set as the argument for > enable and disable functions. > Callback functions will be called when item->counter is larger than zero. This logic sounds complicated to me. I'm afraid that FDW developers may a bit easily misunderstand the logic and make the bug in their FDW. Isn't it simpler to just disable the timeout in core whenever the transaction ends whether committed or aborted, like statement_timeout is disabled after each command? For example, call something like DisableForeignCheckTimeout() in CommitTransaction() etc. > You are right. I think this suggests that error-reporting should be done in the core layer. > For meaningful error reporting, I changed a callback specification > that it should return ForeignServer* which points to downed remote server. This approach seems to assume that FDW must manage all the ForeignServer information so that the callback can return it. Is this assumption valid for all the FDW? How about making FDW trigger a query cancel interrupt by signaling SIGINT to the backend, instead? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION