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

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-admin(at)postgresql(dot)org
Subject: Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Date: 2009-11-12 15:01:40
Message-ID: e51f66da0911120701k48eb0ffare76e7d26ca71690c@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On 11/12/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The other thought is that quickdie should block signals before
> starting to do anything.

There would still be possibility of recursive syslog() calls.
Shouldn't we fix that too?

I'm not sure how exactly. If the recursive elog() must stay, then
perhaps simple 'volatile int' around syslog() ?

--
marko

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2009-11-12 15:24:45 Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Previous Message Tom Lane 2009-11-12 14:35:38 Re: recovery is stuck when children are not processing SIGQUIT from previous crash

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Chernow 2009-11-12 15:09:05 Re: Listen / Notify rewrite
Previous Message Tom Lane 2009-11-12 14:53:26 Re: NULL-handling in aggregate(DISTINCT ...)