Hi,
On 2023-05-05 07:08:39 -0400, Andrew Dunstan wrote:
> If you want to play I can arrange access.
Andrew did - thanks!
A first observeration is that making the shell command slightly more
complicated, by echoing $? after pg_ctl, prevents the error:
/usr/bin/perl -e 'system(qq{"bin/pg_ctl" -D data-C -w -l logfile start > startlog 2>&1}) ;system(qq{"bin/pg_ctl" -D
data-C-w -l logfile stop > stoplog 2>&1;}) ; print $? ? "BANG: $?\n" : "OK\n";'
BANG: 33280
/usr/bin/perl -e 'system(qq{"bin/pg_ctl" -D data-C -w -l logfile start > startlog 2>&1}) ;system(qq{"bin/pg_ctl" -D
data-C-w -l logfile stop > stoplog 2>&1; echo $?}) ; print $? ? "BANG: $?\n" : "OK\n";'
0
OK
So does manually or or via a subshell adding another layer of shell.
As Andrew observed earlier, the issue does not occur when not performing
redirection of the output. One interesting bit there is that the perl docs for
system include:
https://perldoc.perl.org/functions/system
> If there are no shell metacharacters in the argument, it is split into words
> and passed directly to execvp, which is more efficient. On Windows, only the
> system PROGRAM LIST syntax will reliably avoid using the shell; system LIST,
> even with more than one element, will fall back to the shell if the first
> spawn fails.
My guesss is that the issue somehow is triggered around the shell handling.
One relevant bit: If I use strace (from msys) within system, the subprograms
(shell and pg_ctl) actually exit with 0, from what I can tell - but 33280
still is returned. Unfortunately, if I use strace for all of perl, the error
vanishes.
Perhaps are some odd interactions with the stuff that InheritstdHandles()
does?
Andrew, is it ok if modify pg_ctl.c and rebuild? I don't know how "detached"
from the actual buildfarm animal the system you gave me access to is...
Greetings,
Andres Freund