Re: BackgroundPsql swallowing errors on windows
От | Noah Misch |
---|---|
Тема | Re: BackgroundPsql swallowing errors on windows |
Дата | |
Msg-id | 20250216235843.7c.nmisch@google.com обсуждение исходный текст |
Ответ на | Re: BackgroundPsql swallowing errors on windows (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BackgroundPsql swallowing errors on windows
|
Список | pgsql-hackers |
On Sun, Feb 16, 2025 at 06:18:44PM -0500, Tom Lane wrote: > 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?". In the BackgroundPsql case, we have output collection moments for every query while the psql-under-test is running, not just after exit. If I understand the original post right, the specifics are as follows. If $stdout witnesses the result of '\echo BANNER', $stderr should contain anything from psql commands before the \echo. That holds on non-Windows, but the IPC::Run proxy makes it not hold on Windows. > 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. https://github.com/cpan-authors/IPC-Run/commit/2128df3bbcac7e733ac46302c4b1371ffb88fe14 fixed that one. > [1] https://cirrus-ci.com/task/6221238034497536
В списке pgsql-hackers по дате отправления: