Horton

Re: stress test for parallel workers

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Mark Wong <mark@2ndquadrant.com>, Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-10-13T14:50:53Z
Lists: pgsql-hackers 
Hi,

On 2019-10-13 10:29:45 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Probably requires reproducing on a pretty recent kernel first, to have a
> > decent chance of being investigated...
> 
> How recent do you think it needs to be?  The machine I was testing on
> yesterday is under a year old:
>
> uname -r = 4.18.19-100.fc27.ppc64le
> ...
> uname -r = 4.19.15-300.fc29.ppc64le

My experience reporting kernel bugs is that the latest released version,
or even just the tip of the git tree, is your best bet :/. And that
reports using distro kernels - with all their out of tree changes - are
also less likely to receive a response.  IIRC there's a fedora repo with
upstream kernels.

Greetings,

Andres Freund

Commits

  1. In the postmaster, rely on the signal infrastructure to block signals.

  2. Paper over regression failures in infinite_recurse() on PPC64 Linux.

  3. Hack pg_ctl to report postmaster's exit status.

  4. Re-order some regression test scripts for more parallelism.