Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iJ1X8-0002JE-G8 for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Oct 2019 20:29:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iJ1X6-0004sr-RX for pgsql-hackers@arkaria.postgresql.org; Fri, 11 Oct 2019 20:29:04 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iJ1X6-0004si-Ay for pgsql-hackers@lists.postgresql.org; Fri, 11 Oct 2019 20:29:04 +0000 Received: from mail-wr1-x443.google.com ([2a00:1450:4864:20::443]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1iJ1X2-0008IM-UM for pgsql-hackers@postgresql.org; Fri, 11 Oct 2019 20:29:02 +0000 Received: by mail-wr1-x443.google.com with SMTP id q9so13242021wrm.8 for ; Fri, 11 Oct 2019 13:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=evQ6mdY12s3QQ30s72DA7lUs3IjLbplawG/MMfSH+1A=; b=nVVVo01Q9UMlO0H7x/RJs+92TRL3Zqs42PgrhVhpYc4JvDDuMqe2sIP0Ef+P0NfmAR CdtnivvsR9xKTrGbi0lYz1b0BQve33yrShqoTYU5C4QV0BFuzzFZwDPdPPGb071YiI3y i5CZ8anotcQNm/0D+u62oKZ9plDWTQInXSsaaOFHch1GztoQDki+TLWbG5AnE8SoQS5n zj/+jwUdObzReYKWTFidjt/Tf90/KDbRdNoMRPhnzIpBXG8Im6v/OFuSTmEqXh/w+t+L oG2o56GIntbdyzGbBZd78mHOrReJnwGajY/HorucQkUKmi+yM1+aALX0skZJTiWdqyCZ 7n7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=evQ6mdY12s3QQ30s72DA7lUs3IjLbplawG/MMfSH+1A=; b=llRuIsusBbFM7+XHJJniZlrdlRWjFv7/+/gqIGk7LxUtuG9OOWJxCdl1cLAU/EQE/o 8DVQeFKjKgLMG1Q3sLqAyusY3XqEq88MJ2ujdu9zJV3T9V7BZRns7oFP4v1vogllfGyt NztowXj1yd6SH0Nj2rjz7pABIcGRFBh6mEOVQWPH02CJXB+IQmW9Md+S80UhTzchCWWE Y0ZR2BbffUsxqTDIZtZgRWoMfvXJWy2fsZBMs2fxyEryu6aT+YjTMKGcdsW54EYI3zcn o7wWUJUibP/+EXMrlESMp4tD6uFjiaIgakLDLLoqxSFnuhdRXmdpQ4mimBGlrY8MyKHd kC2A== X-Gm-Message-State: APjAAAU64B//FiXwfdS1aIxvE9wBvHzwAWgIjeUeKJSxzMU8HQmwhrle WsELU6lNVtkiDdrjyHsB+FttC0/aNNk= X-Google-Smtp-Source: APXvYqxVHbdkFOlA5JciI+7wOG7c4YJrmtOIF8UBERnjucu0zLlFnNsNCsbi4LJNv67qajE7FdC3hQ== X-Received: by 2002:a5d:6581:: with SMTP id q1mr14262305wru.393.1570825739078; Fri, 11 Oct 2019 13:28:59 -0700 (PDT) Received: from 2ndQuadrant.com (c-67-169-212-172.hsd1.or.comcast.net. [67.169.212.172]) by smtp.gmail.com with ESMTPSA id 207sm16521671wme.17.2019.10.11.13.28.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Oct 2019 13:28:58 -0700 (PDT) Date: Fri, 11 Oct 2019 13:28:53 -0700 From: Mark Wong To: Thomas Munro Cc: Tom Lane , Andrew Dunstan , Justin Pryzby , Andres Freund , pgsql-hackers Subject: Re: stress test for parallel workers Message-ID: <20191011202853.GA23809@2ndQuadrant.com> References: <31032.1565152159@sss.pgh.pa.us> <18537.1570421268@sss.pgh.pa.us> <5350.1570743291@sss.pgh.pa.us> <84813a30-8c34-9c32-7ad5-90d9eefba468@2ndQuadrant.com> <06d6be5a-7af2-ef78-0abc-6bfe500ead87@2ndQuadrant.com> <20032.1570808731@sss.pgh.pa.us> <14878.1570820201@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Oct 12, 2019 at 08:41:12AM +1300, Thomas Munro wrote: > On Sat, Oct 12, 2019 at 7:56 AM Tom Lane wrote: > > This matches up with the intermittent infinite_recurse failures > > we've been seeing in the buildfarm. Those are happening across > > a range of systems, but they're (almost) all Linux-based ppc64, > > suggesting that there's a longstanding arch-specific kernel bug > > involved. For reference, I scraped the attached list of such > > failures in the last three months. I wonder whether we can get > > the attention of any kernel hackers about that. > > Yeah, I don't know anything about this stuff, but I was also beginning > to wonder if something is busted in the arch-specific fault.c code > that checks if stack expansion is valid[1], in a way that fails with a > rapidly growing stack, well timed incoming signals, and perhaps > Docker/LXC (that's on Mark's systems IIUC, not sure about the ARM > boxes that failed or if it could be relevant here). Perhaps the > arbitrary tolerances mentioned in that comment are relevant. This specific one (wobbegon) is OpenStack/KVM[2], for what it's worth... "... cluster is an OpenStack based cluster offering POWER8 & POWER9 LE instances running on KVM ..." But to keep you on your toes, some of my ppc animals are Docker within other OpenStack/KVM instance... Regards, Mark [1] https://github.com/torvalds/linux/blob/master/arch/powerpc/mm/fault.c#L244 [2] https://osuosl.org/services/powerdev/ -- Mark Wong 2ndQuadrant - PostgreSQL Solutions for the Enterprise https://www.2ndQuadrant.com/