Re: issue with meson builds on msys2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: issue with meson builds on msys2
Date
Msg-id 863239.1682523022@sss.pgh.pa.us
Whole thread Raw
In response to Re: issue with meson builds on msys2  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: issue with meson builds on msys2
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Dimos Stamatakis
Date:
Subject: Re: Fix for visibility check on 14.5 fails on tpcc with high concurrency
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: Autogenerate some wait events code and documentation