Re: Getting server crash after running sqlsmith - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Getting server crash after running sqlsmith
Date
Msg-id CAEepm=1BU8_rwjky_0E=nKrQPNup-Z3=S6tDpXS9Uhw7koYydA@mail.gmail.com
Whole thread Raw
In response to Re: Getting server crash after running sqlsmith  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 29, 2017 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Mar 28, 2017 at 2:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Hm ... I don't see a crash here, but I wonder whether you have parameters
>>> set that would cause this query to be run as a parallel query?  Because
>>> pg_rotate_logfile() is marked as parallel-safe in pg_proc, which seems
>>> probably insane.
>
>> /me blinks
>
>> Uh, what's insane about that?  All it does is test a GUC (which is
>> surely parallel-safe) and call SendPostmasterSignal (which seems safe,
>> too).
>
> Well, if you don't like that theory, what's yours?

I can't reproduce this either.  But here's a theory: this query
signals the postmaster repeatedly fast, and with just the right kind
of difficulty scheduling/waking to the postmaster to deliver the
signal on an overloaded machine, maybe there is always a new SIGUSR1
and PMSIGNAL_ROTATE_LOGFILE waiting once the signal handler reaches
PG_SETMASK(&UnBlockSig), at which point it immediately recurses into
the signal handler until it blows the stack.

-- 
Thomas Munro
http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem
Next
From: Robert Haas
Date:
Subject: Re: Getting server crash after running sqlsmith