Re: Recent 027_streaming_regress.pl hangs

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Thomas Munro <thomas.munro@gmail.com>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: 2024-04-04T17:00:55Z
Lists: pgsql-hackers
Hi,

On 2024-04-04 19:00:00 +0300, Alexander Lakhin wrote:
> 26.03.2024 10:59, Andres Freund wrote:
> > Late, will try to look more in the next few days.
> > 
> 
> AFAICS, last 027_streaming_regress.pl failures on calliphoridae,
> culicidae, tamandua occurred before 2024-03-27:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=calliphoridae&dt=2024-03-26%2004%3A07%3A30
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=culicidae&dt=2024-03-22%2013%3A26%3A21
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tamandua&dt=2024-03-24%2007%3A44%3A27
> 
> So it looks like the issue resolved, but there is another apparently
> performance-related issue: deadlock-parallel test failures.

I reduced test concurrency a bit. I hadn't quite realized how the buildfarm
config and meson test concurrency interact.  But there's still something off
with the frequency of fsyncs during replay, but perhaps that doesn't qualify
as a bug.


> A recent one:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2024-04-02%2022%3A20%3A22
> test deadlock-parallel            ... FAILED   345099 ms

> (I could reach similar duration on a slowed-down VM, with JIT enabled as
> on these animals.)
> 
> So, maybe these machines require larger PGISOLATIONTIMEOUT or there is
> still some OS/environment issue there?

Hm, possible. Forcing every query to be JITed, in a debug build of LLVM is
absurdly expensive.

Greetings,

Andres Freund



Commits

  1. Log more info when wait-for-catchup tests time out.

  2. Add a new slot sync worker to synchronize logical slots.