From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
Date: | 2009-11-12 14:35:38 |
Message-ID: | 23748.1258036538@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
Peter Eisentraut <peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Kreen | 2009-11-12 15:01:40 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
Previous Message | Marko Kreen | 2009-11-12 12:19:51 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-12 14:39:45 | Re: not logging caught exceptions |
Previous Message | Merlin Moncure | 2009-11-12 14:30:48 | Re: Listen / Notify rewrite |