Re: stress test for parallel workers
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>,
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-11T21:03:22Z
Lists: pgsql-hackers
On Sat, Oct 12, 2019 at 9:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2019-10-11 14:56:41 -0400, Tom Lane wrote: > >> ... So it's really hard to explain > >> that as anything except a kernel bug: sometimes, the kernel > >> doesn't give us as much stack as it promised it would. And the > >> machine is not loaded enough for there to be any rational > >> resource-exhaustion excuse for that. > > > Linux expands stack space only on demand, thus it's possible to run out > > of stack space while there ought to be stack space. Unfortunately that > > during a stack expansion, which means there's no easy place to report > > that. I've seen this be hit in production on busy machines. > > As I said, this machine doesn't seem busy enough for that to be a > tenable excuse; there's nobody but me logged in, and the buildfarm > critter isn't running. Yeah. As I speculated in the other thread[1], the straightforward can't-allocate-any-more-space-but-no-other-way-to-tell-you-that case, ie, the explanation that doesn't involve a bug in Linux or PostgreSQL, seems unlikely unless we also see other more obvious signs of occasional overcommit problems (ie not during stack expansion) on those hosts, doesn't it? How likely is it that this 1-2MB of stack space is the straw that breaks the camels back, every time? [1] https://www.postgresql.org/message-id/CA%2BhUKGJ_MkqdEH-LmmebhNLSFeyWwvYVXfPaz3A2_p27EQfZwA%40mail.gmail.com
Commits
-
In the postmaster, rely on the signal infrastructure to block signals.
- 8b53dbada4a6 12.5 landed
- 85834023a95e 11.10 landed
- 7753ca49d358 9.6.20 landed
- 4e95733b0864 10.15 landed
- 9abb2bfc0460 13.0 landed
-
Paper over regression failures in infinite_recurse() on PPC64 Linux.
- c7e2364a5f17 12.5 landed
- ae0f7b11f143 14.0 landed
- 855b6f287100 13.1 landed
-
Hack pg_ctl to report postmaster's exit status.
- 6a5084eed495 13.0 landed
-
Re-order some regression test scripts for more parallelism.
- 798070ec058f 12.0 cited