Horton

Re: stress test for parallel workers

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2019-08-07T13:30:46Z
Lists: pgsql-hackers 
On 07/08/2019 02:57, Thomas Munro wrote:
> On Wed, Jul 24, 2019 at 5:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I think I've got to take back the assertion that we've got
>> some lurking generic problem.  This pattern looks way more
>> like a platform-specific issue.  Overaggressive OOM killer
>> would fit the facts on vulpes/wobbegong, perhaps, though
>> it's odd that it only happens on HEAD runs.
> 
> chipmunk also:
> 
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=chipmunk&dt=2019-08-06%2014:16:16
> 
> I wondered if the build farm should try to report OOM kill -9 or other
> signal activity affecting the postmaster.

FWIW, I looked at the logs in /var/log/* on chipmunk, and found no 
evidence of OOM killings. I can see nothing unusual in the OS logs 
around the time of that failure.

- Heikki

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.