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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Marko Kreen <markokr(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash
Date: 2009-12-16 15:48:44
Message-ID: 1260978524.3310.10.camel@fsopti579.F-Secure.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin 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 Content-Type Size
0001-If-there-is-no-sigdelset-define-it-as-a-macro.patch text/x-patch 0 bytes

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Alvaro Herrera 2009-12-16 15:55:49 Re: [ADMIN] recovery is stuck when children are not processing SIGQUIT from previous crash
Previous Message Richard Broersma 2009-12-16 15:13:49 Re: Inheritance in Postgresql ?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-12-16 15:49:32 Re: Patch: Remove gcc dependency in definition of inline functions
Previous Message Kurt Harriman 2009-12-16 15:44:50 PostgreSQL project policy compendium