Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r2bFl-00Ha7q-1E for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Nov 2023 18:01:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r2bFj-00HPno-Ki for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Nov 2023 18:01:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r2bFj-00HPmx-Am for pgsql-hackers@lists.postgresql.org; Mon, 13 Nov 2023 18:01:39 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r2bFg-006Ffw-PL for pgsql-hackers@postgresql.org; Mon, 13 Nov 2023 18:01:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2023062407; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=64EuhF43EuV8ZvRSDbdHXgKJ6LpkjJS4ASN4Hp7+v94=; b=jGORY UoZR+2V+f2P/u5yQVpI0Hpqzc2CpYRMImMgcFlI2aNjUQBCg9NwCL8umZNUJ7wgKM8BGq7msiNKpd aJehb4czAdLrQ+J1l6f1kbYBIfIoEIWkMEJCHlFai2Az0DQyPpzuKUw7PEZfNKI0vDvTrj7g/plso nlRyh1bl8iiltpA9lWuLtyYK4uW6dd6LJZM/5ipHzMuH73lQGgYrWcmPtm5NeRpYJV8pMqwYhis58 kjpgOhCIVW5fA7Oo/FAe3sPgbmPIYRpUq+jIXCvt5rGItkd//AMrit5gBDJBNZhEhaha2px1U7E7L tEFUAYvHnXlE116y18JISKF0Xb4XQ==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1r2bFc-00EDLZ-0R; Mon, 13 Nov 2023 13:01:32 -0500 Date: Mon, 13 Nov 2023 13:01:32 -0500 From: Bruce Momjian To: Tom Lane Cc: Yugo NAGATA , Alvaro Herrera , pgsql-hackers@postgresql.org Subject: Re: Question about non-blocking mode in libpq Message-ID: References: <20210719231129.b2ab655c0d0e80545274c86f@sraoss.co.jp> <202107201605.b3hmz4g6uqqz@alvherre.pgsql> <20210721101509.7e70e0f801a4457a2f6a6174@sraoss.co.jp> <2604997.1698775114@sss.pgh.pa.us> <2666892.1698801066@sss.pgh.pa.us> <2674201.1698804967@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Nov 1, 2023 at 08:47:33AM -0400, Bruce Momjian wrote: > On Tue, Oct 31, 2023 at 10:16:07PM -0400, Tom Lane wrote: > > Bruce Momjian writes: > > > On Tue, Oct 31, 2023 at 09:11:06PM -0400, Tom Lane wrote: > > >> What I'm objecting to is removal of the bit about "if they need to be > > >> called again". That provides a hint that retry is the appropriate > > >> response to a failure. Admittedly, it's not 100% clear, but your > > >> version makes it 0% clear. > > > > > I thought the original docs said you had to re-call on failure (it would > > > not block but it would fail if it could not be sent), while we are now > > > saying that it will be queued in the input buffer. > > > > For these functions in nonblock mode, failure means "we didn't queue it". > > > > > Is retry really something we need to mention now? If out of memory is > > > our only failure case now ("unable to enlarge the buffer because OOM"), > > > is retry really a realistic option? > > > > Well, ideally the application would do something to alleviate the > > OOM problem before retrying. I don't know if we want to go so far > > as to discuss that. I do object to giving the impression that > > failure is impossible, which I think your proposed wording does. > > > > An orthogonal issue with your latest wording is that it's unclear > > whether *unsuccessful* calls to these functions will block. > > Okay, I see your point now. Here is an updated patch that addresses > both issues. Patch applied to master. -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.