Re: issue with meson builds on msys2
От | Andrew Dunstan |
---|---|
Тема | Re: issue with meson builds on msys2 |
Дата | |
Msg-id | b4162cbb-1e75-8887-b93a-5c82eee3551e@dunslane.net обсуждение исходный текст |
Ответ на | Re: issue with meson builds on msys2 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: issue with meson builds on msys2
|
Список | pgsql-hackers |
On 2023-05-15 Mo 19:43, Andres Freund wrote:
Hi, On 2023-05-15 15:30:28 -0700, Andres Freund wrote:As soon as either the pg_ctl for the start, or the whole bash invocation, has stdin redirected, the problem vanishes.For a moment I thought this could be related to InheritStdHandles() - but no, it doesn't make a difference. There's loads of handles referencing cygwin alive in pg_ctl. Based on difference in strace output for bash -c "pg_ctl stop" for the case where start redirected stdin (#1) and where not (#2), it looks like some part of msys / cygwin sees that stdin is alive when preparing to execute "pg_ctl stop", and then runs into trouble. The way we start the child process on windows makes the use of cmd.exe for redirection pretty odd. I couldn't trivially reproduce this with a much simpler case (just nohup sleep). Perhaps it's dependent on a wrapper cmd or such.
I don't know where this all leaves us. It's still more than odd that the start works fine and the stop doesn't.
This piece of code has worked happily for years. It's only a recent installation or update of msys2 that's made the problem appear.
I have implemented a workaround where IPC::Run is available - that means a little extra one-off work for people using msys2, but it's not a huge burden. Beyond that I don't really want to spend a lot more energy on it.
I suppose the alternative would be to change the way the buildfarm calls pg_ctl stop. Do you have a concrete suggestion for that?
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: