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 1m38g8-0000CO-LM for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jul 2021 03:01:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m38g6-000188-2l for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Jul 2021 03:01:46 +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 1m38g5-000180-R3 for pgsql-hackers@lists.postgresql.org; Tue, 13 Jul 2021 03:01:45 +0000 Received: from mx0a-0050f201.pphosted.com ([148.163.145.86]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m38fy-0005xd-SL for pgsql-hackers@postgresql.org; Tue, 13 Jul 2021 03:01:44 +0000 Received: from pps.filterd (m0203369.ppops.net [127.0.0.1]) by mx0b-0050f201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 16CLsZ2K023640 for ; Tue, 13 Jul 2021 12:01:37 +0900 Received: from sraihe.sra.co.jp (sraihe.sra.co.jp [221.255.117.38]) by mx0b-0050f201.pphosted.com with ESMTP id 39r7fuhbcs-1 for ; Tue, 13 Jul 2021 12:01:37 +0900 Received: from srascb.sra.co.jp (srascb [133.137.8.65]) by sraihe.sra.co.jp (Postfix) with ESMTP id 7EF7B2A684B for ; Tue, 13 Jul 2021 12:01:36 +0900 (JST) Received: from sranhm.sra.co.jp (osspc25 [133.137.174.97]) by srascb.sra.co.jp (Postfix) with ESMTP id 70B055800F0 for ; Tue, 13 Jul 2021 12:01:36 +0900 (JST) Received: from yugon-CFSV7-1 (sraihb-hub.sra.co.jp [133.137.8.6]) by sranhm.sra.co.jp (Postfix) with SMTP id 39280A16A4 for ; Tue, 13 Jul 2021 12:01:36 +0900 (JST) Date: Tue, 13 Jul 2021 11:59:49 +0900 From: Yugo NAGATA To: pgsql-hackers@postgresql.org Subject: Question about non-blocking mode in libpq Message-Id: <20210713115949.702986955f8ccf23fa81073c@sraoss.co.jp> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Proofpoint-GUID: hdeUQHVzUbJ5pAU0kFyjmE9besgMNXb6 X-Proofpoint-ORIG-GUID: hdeUQHVzUbJ5pAU0kFyjmE9besgMNXb6 X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=10043 signatures=668682 X-Proofpoint-Spam-Details: rule=spam_low_notspam policy=spam_low score=0 adultscore=0 priorityscore=1501 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=601 clxscore=1034 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107130017 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, During reading the documentation of libpq [1] , I found the following description: In the nonblocking state, calls to PQsendQuery, PQputline, PQputnbytes, PQputCopyData, and PQendcopy will not block but instead return an error if they need to be called again. [1] https://www.postgresql.org/docs/devel/libpq-async.html However, looking into the code, PQsendQuery seems not to return an error in non-bloking mode even if unable to send all data. In such cases, pqSendSome will return 1 but it doesn't cause an error. Moreover, we would not need to call PQsendQuery again. Indead, we need to call PQflush until it returns 0, as documented with regard to PQflush. Do we need to fix the description of PQsetnonblocking? Regards, Yugo Nagata -- Yugo NAGATA