Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash
Date
Msg-id 1260978524.3310.10.camel@fsopti579.F-Secure.com
Whole thread Raw
In response to Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Here is a set of patches to address this issue.

The first one is a small refactoring of the signal setting portability
business.

The second one fixes the SIGQUIT handler inadvertently unblocking
SIGQUIT within itself.

The third one installs an alarm so that if the ereport() call in
quickdie() doesn't finish after 60 seconds, it skips it and finishes up.
The precise logic of this could be debated, but it more or less appears
to get the job done.

Attachment

pgsql-hackers by date:

Previous
From: Kurt Harriman
Date:
Subject: PostgreSQL project policy compendium
Next
From: Tom Lane
Date:
Subject: Re: Patch: Remove gcc dependency in definition of inline functions