On Wed, Mar 29, 2017 at 2:23 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Mar 28, 2017 at 2:36 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
