Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hjNJ7-0004qA-SL for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jul 2019 12:27:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hjNJ4-00010k-Ug for pgsql-hackers@arkaria.postgresql.org; Fri, 05 Jul 2019 12:27:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hjNJ4-00010d-Fg for pgsql-hackers@lists.postgresql.org; Fri, 05 Jul 2019 12:27:14 +0000 Received: from cyclops.postgrespro.ru ([93.174.131.138] helo=mail.postgrespro.ru) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hjNJ1-0004l7-8Y for pgsql-hackers@postgresql.org; Fri, 05 Jul 2019 12:27:13 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id EDC9B21C4606; Fri, 5 Jul 2019 15:27:08 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.102] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id B7D1C21C45FC; Fri, 5 Jul 2019 15:27:08 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1562329628; bh=4wbAkv6WJOwNrE+TEwmiSXfFQEuh/n+VGM1pw3oJIJw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dVCm77KmKCUDJMrQoDm1wle7JOL5Ps5Bf1gcJevmHaNPW3P417iyKYTNeuyBzPn90 ordZYEwcKSLzGckIvjBz4eAnWzSNxYoO0DcQQCm+QzCdQtMwUX5nG2C1ZThAe/jZLH r0AL2p/412ZEyAuwkt4r5B2H+L4gwO3CziXSZ1BA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: Add client connection check during the execution of the query From: Stas Kelvich In-Reply-To: Date: Fri, 5 Jul 2019 15:27:06 +0300 Cc: Tatsuo Ishii , Tom Lane , pgsql-hackers Content-Transfer-Encoding: 7bit Message-Id: <37D9769E-2991-46A9-A65B-498E3CF55D8C@postgrespro.ru> References: <77def86b27e41f0efcba411460e929ae@postgrespro.ru> <19003.1547420739@sss.pgh.pa.us> <20190705.152814.526451304812431065.t-ishii@sraoss.co.jp> To: Thomas Munro X-Mailer: Apple Mail (2.3445.9.1) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On 5 Jul 2019, at 11:46, Thomas Munro wrote: > > On Fri, Jul 5, 2019 at 6:28 PM Tatsuo Ishii wrote: >>> The purpose of this patch is to stop the execution of continuous >>> requests in case of a disconnection from the client. >> >> Pgpool-II already does this by sending a parameter status message to >> the client. It is expected that clients are always prepared to receive >> the parameter status message. This way I believe we could reliably >> detect that the connection to the client is broken or not. > > Hmm. If you send a message, it's basically application-level > keepalive. But it's a lot harder to be sure that the protocol and > socket are in the right state to insert a message at every possible > CHECK_FOR_INTERRUPT() location. Sergey's proposal of recv(MSG_PEEK) > doesn't require any knowledge of the protocol at all, though it > probably does need TCP keepalive to be configured to be useful for > remote connections. Well, indeed in case of cable disconnect only way to detect it with proposed approach is to have tcp keepalive. However if disconnection happens due to client application shutdown then client OS should itself properly close than connection and therefore this patch will detect such situation without keepalives configured. -- Stas Kelvich Postgres Professional: http://www.postgrespro.com The Russian Postgres Company