Thread: Re: issue with meson builds on msys2

Andrew Dunstan <andrew@dunslane.net> writes:
>> For some reason which makes no sense to me the buildfarm animal fails 
>> at the first Stop-Db step. The DB is actually stopped, but pg_ctl 
>> returns a non-zero status. The thing that's really odd is that meson 
>> isn't at all involved in this step. But it's happened enough that I've 
>> had to back off using meson builds on fairywren - I'm going to do more 
>> testing on a new Windows instance.

> Here's a simple illustration of the problem. If I do the identical test 
> with a non-meson build there is no problem:

> pgrunner@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") ; print "fail\n" if $?; '
> waiting for server to shut down....fail

Looking at the pg_ctl source code, the only way I can explain that
printout is that do_stop called wait_for_postmaster_stop which,
after one or more loops, exited via one of its exit() calls.
The lack of any message can be explained if we imagine that
write_stderr() output is going to the bit bucket.  I'd start by
changing those write_stderr's to print_msg(), which visibly
does work; that should confirm the existence of the stderr
issue and show you how wait_for_postmaster_stop is failing.

            regards, tom lane

I wrote:
> Looking at the pg_ctl source code, the only way I can explain that
> printout is that do_stop called wait_for_postmaster_stop which,
> after one or more loops, exited via one of its exit() calls.

Ah, a little too hasty there: it's get_pgpid() that has to be
reaching an exit().

            regards, tom lane

I wrote:

Looking at the pg_ctl source code, the only way I can explain that
printout is that do_stop called wait_for_postmaster_stop which,
after one or more loops, exited via one of its exit() calls.

Ah, a little too hasty there: it's get_pgpid() that has to be
reaching an exit().

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@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@EC2AMAZ-GCB871B UCRT64 ~/bf
$ cat root/HEAD/instkeep.2023-04-25_11-09-41/stoplog
waiting for server to shut down.... done
server stopped

It seems more than odd that we get to where the "server stopped" massage is printed but we get a failure.

cheers

andrew

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

Andrew Dunstan <andrew@dunslane.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@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@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.

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

            regards, tom lane

Andrew Dunstan <andrew@dunslane.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@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@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@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@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@EC2AMAZ-GCB871B UCRT64 ~/bf
$ cat root/HEAD/instkeep.2023-04-25_11-09-41/stoplog.err

pgrunner@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@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