Horton

Re: stress test for parallel workers

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
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:29:45Z
Lists: pgsql-hackers 
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 -m = ppc64le
uname -r = 4.18.19-100.fc27.ppc64le
uname -s = Linux
uname -v = #1 SMP Wed Nov 14 21:53:32 UTC 2018

The latest-by-version-number ppc64 kernel I can find in the buildfarm
is bonito,

uname -m = ppc64le
uname -r = 4.19.15-300.fc29.ppc64le
uname -s = Linux
uname -v = #1 SMP Mon Jan 14 16:21:04 UTC 2019

and that's certainly shown it too.

			regards, tom lane

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.