Re: IPC::Run accepts bug reports - Mailing list pgsql-hackers

From Andres Freund
Subject Re: IPC::Run accepts bug reports
Date
Msg-id 20240619030727.ldp3mcrjbd5fqwj5@awork3.anarazel.de
Whole thread Raw
In response to Re: IPC::Run accepts bug reports  (Andres Freund <andres@anarazel.de>)
Responses Re: IPC::Run accepts bug reports
List pgsql-hackers
Hi,

On 2024-06-18 12:00:13 -0700, Andres Freund wrote:
> On 2024-06-18 10:10:17 -0700, Noah Misch wrote:
> > > 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.

Yep, that did it.  It reliably reproduces if I comment out
the lines below
  # explicitly shut down psql instances gracefully - to avoid hangs
  # or worse on windows
in 021_row_visibility.pl

The logfile ends in
Warning: unable to close filehandle GEN25 properly: Bad file descriptor during global destruction.
Warning: unable to close filehandle GEN20 properly: Bad file descriptor during global destruction.


Even if I cancel the test, I can't rerun it because due to a leftover psql
a) a new temp install can't be made (could be solved by rm -rf)
b) the test's logfile can't be removed (couldn't even rename the directory)

The psql instance needs to be found and terminated first.


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tender Wang
Date:
Subject: Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop()
Next
From: Ashutosh Sharma
Date:
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions