From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, mikael(dot)kjellstrom(at)gmail(dot)com |
Subject: | Re: Making background psql nicer to use in tap tests |
Date: | 2023-04-08 00:02:18 |
Message-ID: | e660a15f-3249-722a-5606-1ec42a20a661@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2023-04-07 Fr 19:14, Daniel Gustafsson wrote:
>> On 8 Apr 2023, at 00:59, Daniel Gustafsson<daniel(at)yesql(dot)se> wrote:
>>
>>> On 8 Apr 2023, at 00:35, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>
>>> Daniel Gustafsson<daniel(at)yesql(dot)se> writes:
>>>>> On 7 Apr 2023, at 23:01, Daniel Gustafsson<daniel(at)yesql(dot)se> wrote:
>>>> Staring at this I've been unable to figure out if there an underlying problem
>>>> here or a flaky testrun, since I can't reproduce it. Maybe the animal owner
>>>> (on cc) have any insights?
>>>> The test has passed on several different platforms in the buildfarm, including
>>>> Linux, Solaris, macOS, NetBSD, FreeBSD and other OpenBSD animals. It also
>>>> passed in an OpenBSD VM running with our Cirrus framework.
>>> prion and mantid have now failed with the same symptom. I don't
>>> see a pattern, but it's not OpenBSD-only. It will be interesting
>>> to see if the failure is intermittent or not on those animals.
> morepork has failed again, which is good, since intermittent failures are
> harder to track down.
>
>> It would be interesting to know how far in the pumped input they get, if they
>> time out on the first one with nothing going through? Will investigate further
>> tomorrow to see.
> Actually, one quick datapoint. prion and mantid report running IPC::Run
> version 0.92, and morepork 0.96. Animals that pass are running 20180523.0,
> 20200505.0, 20220807.0 or similar versions. We don't print the IO::Pty version
> during configure, but maybe this is related to older versions of the modules
> and this test (not all of them apparently) need to SKIP if IO::Pty is missing
> or too old? Somewhere to start looking at the very least.
Those aren't CPAN version numbers. See <https://metacpan.org/pod/IO::Pty>
prion was running 1.10 (dated to 2010). I have just updated it to 1.17
(the CPAN latest). We'll see if that makes a difference.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-04-08 00:05:10 | Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? |
Previous Message | Jehan-Guillaume de Rorthais | 2023-04-08 00:01:19 | Re: Memory leak from ExecutorState context? |