Re: BackgroundPsql swallowing errors on windows - Mailing list pgsql-hackers

From Noah Misch
Subject Re: BackgroundPsql swallowing errors on windows
Date
Msg-id 20250216235843.7c.nmisch@google.com
Whole thread Raw
In response to Re: BackgroundPsql swallowing errors on windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BackgroundPsql swallowing errors on windows
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: BackgroundPsql swallowing errors on windows
Next
From: Andres Freund
Date:
Subject: Re: BackgroundPsql swallowing errors on windows