Re: Recent 027_streaming_regress.pl hangs
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: 2024-03-26T04:28:32Z
Lists: pgsql-hackers
Hi, On 2024-03-26 00:00:38 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.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
Commits
-
Log more info when wait-for-catchup tests time out.
- e57296ed4867 17.0 landed
- 2aecbd752616 18.0 landed
-
Add a new slot sync worker to synchronize logical slots.
- 93db6cbda037 17.0 cited