Re: recovery is stuck when children are not processing SIGQUIT from previous crash - Mailing list pgsql-admin

From Tom Lane
Subject Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Date
Msg-id 23748.1258036538@sss.pgh.pa.us
Whole thread Raw
In response to Re: recovery is stuck when children are not processing SIGQUIT from previous crash  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: recovery is stuck when children are not processing SIGQUIT from previous crash  (Marko Kreen <markokr@gmail.com>)
List pgsql-admin
Peter Eisentraut <peter_e@gmx.net> writes:
>>> strace on the backend processes all showed them waiting at
>>> futex(0x7f1ee5e21c90, FUTEX_WAIT_PRIVATE, 2, NULL
>>> Notably, the first argument was the same for all of them.

> Looks like a race condition or lockup in the syslog code.

Hm, why are there two <signal handler> calls in the stack?
The only thing I can think of is that we sent SIGQUIT twice.
That's probably bad --- is there any obvious path through
the postmaster that would do that?

The other thought is that quickdie should block signals before
starting to do anything.

            regards, tom lane

pgsql-admin by date:

Previous
From: Marko Kreen
Date:
Subject: Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Next
From: Marko Kreen
Date:
Subject: Re: recovery is stuck when children are not processing SIGQUIT from previous crash