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 1nbTbX-0004Tk-Lh for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 20:47:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nbTbW-0000q5-Hz for pgsql-hackers@arkaria.postgresql.org; Mon, 04 Apr 2022 20:47:14 +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 1nbTbW-0000pw-8k for pgsql-hackers@lists.postgresql.org; Mon, 04 Apr 2022 20:47:14 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbTbT-0001mH-Cp for pgsql-hackers@postgresql.org; Mon, 04 Apr 2022 20:47:13 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 234Kl4P22163178; Mon, 4 Apr 2022 16:47:04 -0400 From: Tom Lane To: Mark Dilger cc: Thomas Munro , PostgreSQL-development , Joshua Brindle , Robert Haas , Andrew Dunstan , Jeff Davis , Joe Conway Subject: Re: New Object Access Type hooks In-reply-to: References: <47F87A0E-C0E5-43A6-89F6-D403F2B45175@enterprisedb.com> <17BD82D7-49AC-40C9-8204-E7ADD30321A0@enterprisedb.com> <1918971.1649091790@sss.pgh.pa.us> <1922986.1649094077@sss.pgh.pa.us> <1923706.1649094673@sss.pgh.pa.us> <1925660.1649095626@sss.pgh.pa.us> <2BD8BDA8-A963-4D64-8B69-8F7EDF9AEA2D@enterprisedb.com> <1974785.1649098875@sss.pgh.pa.us> <1975199.1649099110@sss.pgh.pa.us> Comments: In-reply-to Mark Dilger message dated "Mon, 04 Apr 2022 13:28:17 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2163176.1649105224.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 04 Apr 2022 16:47:04 -0400 Message-ID: <2163177.1649105224@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Mark Dilger writes: >> On Apr 4, 2022, at 12:05 PM, Tom Lane wrote: >> So scratch that. Maybe we'd better add "could not send data to server" >> to the regex? > If it fails in pqsecure_raw_write(), you get either "server closed the c= onnection unexpectedly" or "could not send data to server". Do we need to= support pgtls_write() or pg_GSS_write(), which have different error messa= ges? Don't see why, since this test sets up a new cluster in which neither is enabled. > Is it possible that pgFlush will call pqSendSome which calls pqReadData = before trying to write anything, and get back a "could not receive data fr= om server" from pqsecure_raw_read()? Yeah, it's plausible to get a failure on either the write or read side depending on timing. Perhaps libpq should be trying harder to make those cases look alike, but this test is about server behavior not libpq behavior, so I'm inclined to just make it lax. regards, tom lane