Re: recovery is stuck when children are not processing SIGQUIT from previous crash

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

In response to

Responses

Browse pgsql-admin by date

  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

Browse pgsql-hackers by date

  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