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: Marko Kreen <markokr(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Date: 2009-11-12 20:58:05
Message-ID: 16154.1258059485@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:
> On tor, 2009-11-12 at 10:45 -0500, Tom Lane wrote:
>> In practice the code path isn't sufficiently used or critical
>> enough to be worth trying to make that bulletproof.

> Well, the subject line is "recovery is stuck". Not critical enough?

The particular case looks like it could be solved by disabling
interrupts at the start of quickdie(). My point is that doing more than
that is going to involve a large amount of work for small amount of
return.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Joe Miller 2009-11-13 15:47:37 unix_socket_group problem
Previous Message Marko Kreen 2009-11-12 20:37:03 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 21:06:19 Re: Python 3.1 support
Previous Message Tom Lane 2009-11-12 20:55:37 Re: ALTER TABLE...ALTER COLUMN vs inheritance