pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Mark Wong <mark@2ndquadrant.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: stress test for parallel workers
Date: Fri, 11 Oct 2019 16:13:46 -0400
Message-ID: <18266.1570824826@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGKNgufn12Uh4iEh5y=JkEnUBWnLLmi8L4zwzMunFeKwSA@mail.gmail.com>
References: <20190723162703.GM22387@telsasoft.com>
	<6762.1563902927@sss.pgh.pa.us>
	<20190723174222.GO22387@telsasoft.com>
	<CA+hUKGLch1bNWdG-G8YaeJbyVsper6hG86Ugx9tSWG3=a1R89Q@mail.gmail.com>
	<32179.1563919918@sss.pgh.pa.us>
	<CA+hUKGKZS32Lx1zViq0W8omCjHjBsN=dJZ8nX-rkhv1W=b802Q@mail.gmail.com>
	<17389.1563945314@sss.pgh.pa.us>
	<CA+hUKGL6cDyb2maq2P60cEsjFK=3saBCAj7sDzE3jysL-PRwqg@mail.gmail.com>
	<31032.1565152159@sss.pgh.pa.us>
	<CA+hUKGJNS6gZ=w=+wxjqhmck-voJ7FBuejHnw8mQgAp2yt0A9g@mail.gmail.com>
	<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>
	<CA+hUKGKNgufn12Uh4iEh5y=JkEnUBWnLLmi8L4zwzMunFeKwSA@mail.gmail.com>

Thomas Munro <thomas.munro@gmail.com> writes:
> 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.
> [1] https://github.com/torvalds/linux/blob/master/arch/powerpc/mm/fault.c#L244

Hm, the bit about "we'll allow up to 1MB unconditionally" sure seems
to match up with the observations here.  I also wonder about the
arbitrary definition of "a long way" as 2KB.  Could it be that that
misbehaves in the face of a userland function with more than 2KB of
local variables?

It's not very clear how those things would lead to an intermittent
failure though.  In the case of the postmaster crashes, we now see
that timing of signal receipts is relevant.  For infinite_recurse,
maybe it only fails if an sinval interrupt happens at the wrong time?
(This theory would predict that commit 798070ec0 made the problem
way more prevalent than it had been ... need to go see if the
buildfarm history supports that.)

			regards, tom lane





view thread (60+ messages)  latest in thread

Message-ID: <18266.1570824826@sss.pgh.pa.us>
Permalink:  ../18266.1570824826@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/18266.1570824826@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, andrew.dunstan@2ndquadrant.com, mark@2ndquadrant.com, pryzby@telsasoft.com, andres@anarazel.de
  Subject: Re: stress test for parallel workers
  In-Reply-To: <18266.1570824826@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox