Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-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

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-11-12 21:06:19
Subject: Re: Python 3.1 support
Previous:From: Tom LaneDate: 2009-11-12 20:55:37
Subject: Re: ALTER TABLE...ALTER COLUMN vs inheritance

pgsql-admin by date

Next:From: Joe MillerDate: 2009-11-13 15:47:37
Subject: unix_socket_group problem
Previous:From: Marko KreenDate: 2009-11-12 20:37:03
Subject: Re: recovery is stuck when children are not processing SIGQUIT from previous crash

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group