| From: | Marko Kreen <markokr(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
| Date: | 2009-11-12 12:19:51 |
| Message-ID: | e51f66da0911120419u31598de4y8771df7a8b6bf2ea@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin pgsql-hackers |
On 11/12/09, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2009-09-26 at 12:19 -0400, Tom Lane wrote:
> > 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.
> >
> > Probably means they are blocked on semaphores. Stack traces would
> > be much more informative ...
> Looks like a race condition or lockup in the syslog code.
AFAICS syslog() is not safe to use in signal handler:
http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03
--
marko
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-11-12 14:35:38 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
| Previous Message | Peter Eisentraut | 2009-11-12 12:02:21 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2009-11-12 12:45:35 | Re: write ahead logging in standby (streaming replication) |
| Previous Message | Peter Eisentraut | 2009-11-12 12:02:21 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |