From: Tom Lane <tgl@sss.pgh.pa.us>
To: david@swarm64.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16673: Stack depth limit exceeded error while running
 sysbench TPC-C
In-reply-to: <16673-d278c604f8e34ec0@postgresql.org>
References: <16673-d278c604f8e34ec0@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 15 Oct 2020 12:43:27 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3679450.1602770971.1@sss.pgh.pa.us>
Date: Thu, 15 Oct 2020 10:09:31 -0400
Message-ID: <3679451.1602770971@sss.pgh.pa.us>
Precedence: bulk

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