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
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 |
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 |