Re: issue with meson builds on msys2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: issue with meson builds on msys2
Date: 2023-05-15 20:01:39
Message-ID: 26b0ebdb-3e7c-d562-620d-8e2f17286ff9@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers


On 2023-05-15 Mo 15:38, Andres Freund wrote:
> 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

You're now testing something else, namely the return of the echo rather
than the call to pg_ctl, so I don't think this is any kind of answer. It
would just be ignoring the result of pg_ctl.

>
> 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?

I observed the same thing with strace. Kind of a Heisenbug.

>
> 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...
>

Feel free to do anything you want. This is a completely separate
instance from the buildfarm animals. When we're done with this issue the
EC2 instance will go away.

If you use the script just run in test mode or from-source mode, so it
doesn't try to report results (that would fail anyway, as it doesn't
have a registered secret). You might have to force have_ipc_run to 0. Or
you can just build / install manually.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2023-05-15 20:13:26 Re: issue with meson builds on msys2
Previous Message Andres Freund 2023-05-15 19:38:17 Re: issue with meson builds on msys2

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2023-05-15 20:04:53 Re: Upgrade of git.postgresql.org
Previous Message Andres Freund 2023-05-15 19:38:17 Re: issue with meson builds on msys2