Re: Recent 027_streaming_regress.pl hangs

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)

In response to

Responses

Browse pgsql-hackers by date

  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`