Re: issue with meson builds on msys2

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: issue with meson builds on msys2
Date: 2023-04-26 19:10:09
Message-ID: b4d0e4e2-bc1d-17c1-e265-3b13d6ad77cd@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers


On 2023-04-26 We 11:30, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net> writes:
>> If I redirect the output to a file (which is what the buildfarm client
>> actually does), it seems like it completes successfully, but I still get
>> a non-zero exit:
>> pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
>> $ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41";
>> system("bin/pg_ctl -D data-C -l logfile stop > stoplog 2>&1") ; print
>> "BANG\n" if $?; '
>> BANG
>> pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
>> $ cat root/HEAD/instkeep.2023-04-25_11-09-41/stoplog
>> waiting for server to shut down.... done
>> server stopped
> Thats ... just wacko. do_stop() emits "waiting for server to shut
> down...", "done", and "server stopped" in the same way (via print_msg).
> How is it that all three messages show up in one context but not the
> other? Could wait_for_postmaster_stop or get_pgpid be bollixing the
> stdout channel somehow? Try redirecting stdout and stderr separately
> to see if that proves anything.

Doesn't seem to prove much:

pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41";
system("bin/pg_ctl -D data-C -l logfile stop > stoplog.out 2>
stoplog.err") ; print "BANG\n" if $?; '
BANG

pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
$ cat root/HEAD/instkeep.2023-04-25_11-09-41/stoplog.out
waiting for server to shut down.... done
server stopped

pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
$ cat root/HEAD/instkeep.2023-04-25_11-09-41/stoplog.err

pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf

>
>> It seems more than odd that we get to where the "server stopped" massage
>> is printed but we get a failure.
> Indeed, that's even weirder. do_stop() returns directly to the
> exit(0) in main().
>
>

And if I call it via IPC::Run it works:

pgrunner(at)EC2AMAZ-GCB871B UCRT64 ~/bf
$ /usr/bin/perl -e 'chdir "root/HEAD/instkeep.2023-04-25_11-09-41"; use
IPC::Run; my ($out, $err) = ("",""); IPC::Run::run ["bin/pg_ctl", "-D",
"data-C", "stop"], \"",\$out,\$err ; print "BANG\n" if $?; print "out:
$out\n" if $out; print "err: $err\n" if $err;'
out: waiting for server to shut down.... done
server stopped

It seems there is something odd in how msys perl (not ucrt perl)
implements system() that is tickled by this, but why that should only
occur when it's built using meson is completely beyond me. It should be
just another executable. And pg_ctl is behaving properly as far as we
can see. I'm not quite sure where to go from here. I guess I can try to
see if we have IPC::Run and if so use it. That would probably get me
over the hurdle for fairywren. This has already consumed far too much of
my time.

cheers

andrew

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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2023-04-27 04:36:22 pgsql: Rework code defining default compression for dir/custom formats
Previous Message Tom Lane 2023-04-26 15:30:22 Re: issue with meson builds on msys2

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-04-26 19:44:47 Re: run pgindent on a regular basis / scripted manner
Previous Message Melih Mutlu 2023-04-26 18:53:16 Re: pg_stat_io for the startup process