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 17:13:04 -0400
Message-ID: <21051.1570828384@sss.pgh.pa.us> (raw)
In-Reply-To: <18266.1570824826@sss.pgh.pa.us>
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>
	<18266.1570824826@sss.pgh.pa.us>

I wrote:
> 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.)

That seems to fit, roughly: commit 798070ec0 moved errors.sql to execute
as part of a parallel group on 2019-04-11, and the first failure of the
infinite_recurse test happened on 2019-04-27.  Since then we've averaged
about one such failure every four days, which makes a sixteen-day gap a
little more than you'd expect, but not a huge amount more.  Anyway,
I do not see any other commits in between that would plausibly have
affected this.

In other news, I reproduced the problem with gcc on wobbegong's host,
and confirmed that the gcc build uses less stack space: one recursive
cycle of reaper() and sigusr1_handler() consumes 14768 bytes with clang,
but just 9296 bytes with gcc.  So the evident difference in failure rate
between wobbegong and vulpes is nicely explained by that.  Still no
theory about pg_upgrade versus vanilla "make check" though.  I did manage
to make it happen during "make check" by dint of reducing the "ulimit -s"
setting, so it's *possible* for it to happen there, it just doesn't.
Weird.

			regards, tom lane





view thread (60+ messages)  latest in thread

Message-ID: <21051.1570828384@sss.pgh.pa.us>
Permalink:  ../21051.1570828384@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/21051.1570828384@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: <21051.1570828384@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