Re: BackgroundPsql swallowing errors on windows
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2025-02-16T23:18:44Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
tests: BackgroundPsql: Fix potential for lost errors on windows
- bb2bf22761e1 13.21 landed
- c21ebcca7965 14.18 landed
- 70b650d18553 15.13 landed
- 4c9397c374d9 16.9 landed
- f61769adaa62 17.5 landed
- 8b886a4e3488 18.0 landed
-
Improve handling of empty query results in BackgroundPsql::query()
- 70291a3c66ec 18.0 cited
-
Extend Cluster.pm's background_psql() to be able to start asynchronously
- ba08edb06545 18.0 cited
Noah Misch <noah@leadboat.com> writes: > From the slow proxy's perspective, it can't rule out the program under test > having done those two write() calls. The proxy doesn't have enough > information to reconstruct the original four write() calls. What prevents > 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=bla -Dnull=null -Dtrue=true -Done=1 -Dzero=0.0 -Dbadtrue=trueXXX -Dmaxint=9223372036854775807 -Dminint=-9223372036854775808 -M prepared -f /Users/admin/pgsql/build/testrun/pgbench/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 status (got 2 vs expected 2) [17:27:47.409](0.000s) ok 274 - pgbench script error: shell bad command stdout /(?^:processed: 0/1)/ [17:27:47.409](0.000s) not ok 275 - pgbench script error: shell bad command stderr /(?^:\(shell\) .* meta-command failed)/ [17:27:47.409](0.000s) # Failed test 'pgbench script error: shell bad command stderr /(?^:\(shell\) .* meta-command failed)/' # at /Users/admin/pgsql/src/bin/pgbench/t/001_pgbench_with_server.pl line 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