Re: BUG #16673: Stack depth limit exceeded error while running sysbench TPC-C
David Geier <david@swarm64.com>
From: David Geier <david@swarm64.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-bugs@lists.postgresql.org, Norman Heino <norman.heino@swarm64.com>
Date: 2020-10-19T08:43:06Z
Lists: pgsql-bugs
Hi Tom, Thanks for the quick reply. We gonna try it with PSQL 13 and let you know if the bug still appears. Cheers David On 15.10.20 16:09, Tom Lane wrote: > PG Bug reporting form <noreply@postgresql.org> writes: >> [ signal recursion in postmaster ] > This looks like the same issue that we fixed in HEAD/v13 just about > a year ago: > > Author: Tom Lane <tgl@sss.pgh.pa.us> > Branch: master Release: REL_13_BR [9abb2bfc0] 2019-10-13 15:48:26 -0400 > > In the postmaster, rely on the signal infrastructure to block signals. > > POSIX sigaction(2) can be told to block a set of signals while a > signal handler executes. Make use of that instead of manually > blocking and unblocking signals in the postmaster's signal handlers. > This should save a few cycles, and it also prevents recursive > invocation of signal handlers when many signals arrive in close > succession. We have seen buildfarm failures that seem to be due to > postmaster stack overflow caused by such recursion (exacerbated by > a Linux PPC64 kernel bug). > > This doesn't change anything about the way that it works on Windows. > Somebody might consider adjusting port/win32/signal.c to let it work > similarly, but I'm not in a position to do that. > > For the moment, just apply to HEAD. Possibly we should consider > back-patching this, but it'd be good to let it age awhile first. > > Discussion: https://postgr.es/m/14878.1570820201@sss.pgh.pa.us > > Maybe now it's aged enough to back-patch? > > regards, tom lane
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