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 1tjnuX-00DZ7K-57 for pgsql-hackers@arkaria.postgresql.org; Sun, 16 Feb 2025 23:18:53 +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 1tjnuV-00BUgN-IV for pgsql-hackers@arkaria.postgresql.org; Sun, 16 Feb 2025 23:18:51 +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 1tjnuV-00BUgE-8n for pgsql-hackers@lists.postgresql.org; Sun, 16 Feb 2025 23:18:51 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tjnuS-001EfK-2T for pgsql-hackers@postgresql.org; Sun, 16 Feb 2025 23:18:50 +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 51GNIihb684216; Sun, 16 Feb 2025 18:18:44 -0500 From: Tom Lane To: Noah Misch cc: Andres Freund , pgsql-hackers@postgresql.org Subject: Re: BackgroundPsql swallowing errors on windows In-reply-to: <20250216223951.a3.nmisch@google.com> References: <20250216173943.b6.nmisch@google.com> <20250216184740.55.nmisch@google.com> <20250216223951.a3.nmisch@google.com> Comments: In-reply-to Noah Misch message dated "Sun, 16 Feb 2025 14:39:51 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <684213.1739747924.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 16 Feb 2025 18:18:44 -0500 Message-ID: <684214.1739747924@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Noah Misch writes: > From the slow proxy's perspective, it can't rule out the program under t= est > having done those two write() calls. The proxy doesn't have enough > information to reconstruct the original four write() calls. What preven= ts > that anomaly? Yeah, I think it's hopeless to expect that we can disambiguate the order of writes to two different pipes. For the problem at hand, though, it seems like we don't really need to do that. Rather, the question is "when we detect that the program-under-test has exited, can we be sure we have collected all of its output?". I think that IPC::Run may be screwing up here, because I have seen non-Windows CI failures that look like it didn't read all the stderr output. For example, this pgbench test failure on macOS from [1]: # Running: pgbench -n -t 1 -Dfoo=3Dbla -Dnull=3Dnull -Dtrue=3Dtrue -Done=3D= 1 -Dzero=3D0.0 -Dbadtrue=3DtrueXXX -Dmaxint=3D9223372036854775807 -Dminint= =3D-9223372036854775808 -M prepared -f /Users/admin/pgsql/build/testrun/pg= bench/001_pgbench_with_server/data/t_001_pgbench_with_server_main_data/001= _pgbench_error_shell_bad_command [17:27:47.408](0.061s) ok 273 - pgbench script error: shell bad command st= atus (got 2 vs expected 2) [17:27:47.409](0.000s) ok 274 - pgbench script error: shell bad command st= dout /(?^:processed: 0/1)/ [17:27:47.409](0.000s) not ok 275 - pgbench script error: shell bad comman= d stderr /(?^:\(shell\) .* meta-command failed)/ [17:27:47.409](0.000s) # Failed test 'pgbench script error: shell bad co= mmand stderr /(?^:\(shell\) .* meta-command failed)/' # at /Users/admin/pgsql/src/bin/pgbench/t/001_pgbench_with_server.pl lin= e 1466. # '' # doesn't match '(?^:\(shell\) .* meta-command failed)' The program's exited with a failure code as expected, and we saw (some of?) the expected stdout output, but stderr output is reported to be empty. regards, tom lane [1] https://cirrus-ci.com/task/6221238034497536