Re: Getting server crash after running sqlsmith

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Getting server crash after running sqlsmith
Date: 2017-03-29 01:49:10
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Wed, Mar 29, 2017 at 2:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Mar 28, 2017 at 2:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-03-29 01:49:42 Re: Getting server crash after running sqlsmith
Previous Message Claudio Freire 2017-03-29 01:46:12 Re: Vacuum: allow usage of more than 1GB of work mem