From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Recent 027_streaming_regress.pl hangs |
Date: | 2024-03-14 20:28:19 |
Message-ID: | CA+hUKGJScMYiyM5SmwQ23Fwh1394=vQ+nxiV0ke2WocupThs+Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Mar 15, 2024 at 7:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> Could it be that the timeout (360 sec?) is just not enough for the test
> under the current (changed due to switch to meson) conditions?
Hmm, well it looks like he switched over to meson around 42 days ago
2024-02-01, looking at "calliphoridae" (skink has the extra
complication of valgrind, let's look at a more 'normal' animal
instead). The first failure that looks like that on calliphoridae is
19 days ago 2024-02-23, and after that it's happening every 3 days,
sometimes in clusters.
https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=calliphoridae&br=HEAD
But you're right that under meson the test takes a lot longer, I guess
due to increased concurrency:
287/287 postgresql:recovery / recovery/027_stream_regress
OK 684.50s 6 subtests passed
With make we don't have an individual time per script, but for for all
of the recovery tests we had for example:
t/027_stream_regress.pl ............... ok
All tests successful.
Files=39, Tests=542, 65 wallclock secs ( 0.26 usr 0.06 sys + 20.16
cusr 31.65 csys = 52.13 CPU)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-03-14 20:33:41 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Tom Lane | 2024-03-14 20:08:23 | Re: Possibility to disable `ALTER SYSTEM` |