| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Subject: | Re: Recent 027_streaming_regress.pl hangs |
| Date: | 2024-03-26 04:28:32 |
| Message-ID: | 20240326042832.4urkzpnwhawyngah@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2024-03-26 00:00:38 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > I think there must be some actual regression involved. The frequency of
> > failures on HEAD vs failures on 16 - both of which run the tests concurrently
> > via meson - is just vastly different.
>
> Are you sure it's not just that the total time to run the core
> regression tests has grown to a bit more than what the test timeout
> allows for?
You're right, that could be it - in a way at least, the issue is replay not
catching up within 180s, so it'd have to be the data volume growing, I think.
But it doesn't look like the regression volume meaningfully grew around that
time?
I guess I'll try to write a buildfarm database query to extract how long that
phase of the test took from all runs on my menagerie, not just the failing
one, and see if there's a visible trend.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2024-03-26 04:34:29 | Re: Improve eviction algorithm in ReorderBuffer |
| Previous Message | Hayato Kuroda (Fujitsu) | 2024-03-26 04:26:43 | RE: speed up a logical replica setup |