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 1m1VdB-0004aU-Ok for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jul 2021 15:08:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1Vd9-00063F-OQ for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jul 2021 15:07:59 +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 1m1Vd9-000636-Fh for pgsql-hackers@lists.postgresql.org; Thu, 08 Jul 2021 15:07:59 +0000 Received: from codesynthesis.com ([188.40.148.39]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Vd3-0007N6-35 for pgsql-hackers@lists.postgresql.org; Thu, 08 Jul 2021 15:07:59 +0000 Received: from brak.codesynthesis.com (unknown [105.187.34.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by codesynthesis.com (Postfix) with ESMTPSA id DFC715F16D; Thu, 8 Jul 2021 15:07:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codesynthesis.com; s=mail1; t=1625756871; bh=/gG3aVazWD+KbdeLoy+tBw1F7LAhIuDi0+daGSINlz4=; h=Date:From:To:Subject:Message-ID:MIME-Version:From; b=DajmtN4Y6R34KvSdO5kyjpZPimt8kXiP3bvfP7+7XHPduch1sakB7IzytOVvvSYnX Sz5fLk3rkHCMf5i54wRy6+nrgeijjegzC+WJtRSnk8buzIeF00ApgDoWvdGEw5gOTO KzQBodjYW6ZBhw3vwnDxIa+8Xbg17kmimNfDTU+5YkCIxv8GYWvCBW+4EX+4OUk5c0 q68Ci8u88xA9pzV3dKBV5KFfeWeeeMDhCM1fF5hVE4jpkxbrQiJ/fwCl2KTNVfP2zR hX9G9dCnnj49coP+MD1Drx68gFFdLsv5ZJBFxpwAnl1GiMd71ZIilE+FbmfCBNIgyo uNcyCzl92+KSA== Received: by brak.codesynthesis.com (Postfix, from userid 1000) id AAB7A1A800C4; Thu, 8 Jul 2021 17:07:44 +0200 (SAST) Date: Thu, 8 Jul 2021 17:07:44 +0200 From: Boris Kolpackov To: Alvaro Herrera Cc: pgsql-hackers@lists.postgresql.org, Michael Paquier , Andrew Dunstan , Peter Geoghegan Subject: Re: Pipeline mode and PQpipelineSync() Message-ID: References: <202107081357.xbplnti7szms@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202107081357.xbplnti7szms@alvherre.pgsql> Organization: Code Synthesis User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Alvaro Herrera writes: > On 2021-Jul-08, Boris Kolpackov wrote: > > > Alvaro Herrera writes: > > > > > Hmm ... aren't you trying to read more results than you sent queries? > > > > Hm, but should I be able to? Or, to put another way, should PQisBusy() > > indicate there is a result available without me sending a query for it? > > That sounds very counter-intuitive to me. > > That seems a fair complaint, but I think PQisBusy is doing the right > thing per its charter. It is documented as "would PQgetResult block?" > and it is returning correctly that PQgetResult would not block in that > situation, because no queries are pending. Well, that's one way to view it. But in this case one can say that the entire pipeline is still "busy" since we haven't seen the PQpipelineSync() call. So maybe we could change the charter only for this special situation (that is, inside the pipeline)? But I agree, it may not be worth the trouble and a note in the documentation may be an acceptable "solution". I am happy to go either way, just let me know what it will be. And also if the latest patch to libpq that you have shared[1] is still necessary. [1] https://www.postgresql.org/message-id/202107061747.tlss7f2somqf%40alvherre.pgsql