Hi, On 2024-06-18 10:10:17 -0700, Noah Misch wrote: > On Mon, Jun 17, 2024 at 11:11:17AM -0700, Andres Freund wrote: > > On 2024-06-15 16:48:24 -0700, Noah Misch wrote: > > > On Sat, Jun 15, 2024 at 01:26:57PM -0400, Robert Haas wrote: > > > > The one > > > > thing I know about that *I* think is a pretty big problem about Perl > > > > is that IPC::Run is not really maintained. > > > > > > I don't see in https://github.com/cpan-authors/IPC-Run/issues anything > > > affecting PostgreSQL. If you know of IPC::Run defects, please report > > > them. > > > If I knew of an IPC::Run defect affecting PostgreSQL, I likely would work > > > on > > > it before absurdity like > > > https://github.com/cpan-authors/IPC-Run/issues/175 > > > NetBSD-10-specific behavior coping. > > > > 1) Sometimes hangs hard on windows if started processes have not been shut > > down before script exits. I've mostly encountered this via the > > buildfarm / > > CI, so I never had a good way of narrowing this down. It's very painful > > because things seem to often just get stuck once that happens. > > That's bad. Do you have a link to a log, a thread discussing it, or even just > one of the test names experiencing it?
I'm unfortunately blanking on the right keyword right now. I think it basically required not shutting down a process started in the background with IPC::Run. I'll try to repro it by removing some ->finish or ->quit calls. There's also a bunch of tests that have blocks like # some Windows Perls at least don't like IPC::Run's start/kill_kill regime. skip "Test fails on Windows perl", 2 if $Config{osname} eq 'MSWin32'; Some of them may have been related to this. > > 2) If a subprocess dies in an inopportune moment, IPC::Run dies with "ack > > Broken pipe:" (in _do_filters()). There's plenty reports of this on the > > list, and I've hit this several times personally. It seems to be timing > > dependent, I've encountered it after seemingly irrelevant ordering > > changes. > > > > I suspect I could create a reproducer with a bit of time. > > I've seen that one. If the harness has data to write to a child, the child > exiting before the write is one way to reach that. Perhaps before exec(), > IPC::Run should do a non-blocking write from each pending IO. That way, small > writes never experience the timing-dependent behavior. I think the question is rather, why is ipc run choosing to die in this situation and can that be fixed? > > 3) It's very slow on windows (in addition to the windows process > > slowness). That got to be fixable to some degree. > > Agreed. For the next release, today's git has some optimizations. There are > other known-possible Windows optimizations not implemented. Yay! Greetings, Andres Freund