From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marko Kreen <markokr(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
Date: | 2009-11-12 15:45:45 |
Message-ID: | 24993.1258040745@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
Marko Kreen <markokr(at)gmail(dot)com> writes:
> You talked about blocking in quickdie(), but you'd need
> to block in elog().
I'm not really particularly worried about that case. By that logic,
we could not use quickdie at all, because any part of the system
might be doing something that wouldn't survive being interrupted.
In practice the code path isn't sufficiently used or critical
enough to be worth trying to make that bulletproof.
It does strike me that we might someday add code to the postmaster
to SIGKILL processes that fail to exit in a reasonably prompt fashion
after SIGQUIT, on the theory that they might be stuck in something
like this. But for now, I'm more interested in a one-line fix that
will deal with the actually observed case ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Lister | 2009-11-12 18:04:30 | recovery lag question |
Previous Message | Marko Kreen | 2009-11-12 15:34:53 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2009-11-12 15:48:44 | Re: Listen / Notify rewrite |
Previous Message | Marko Kreen | 2009-11-12 15:34:53 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |