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

  1. In the postmaster, rely on the signal infrastructure to block signals.