From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 20:37:03 |
Message-ID: | e51f66da0911121237s6d0f0316sde11e4a3e6038b8b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On 11/12/09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.
Not really - we'd need to care only about parts that quickdie()
(or any other signal handler) wants to use. Which basically means
elog() only.
OK, full elog() is a beast, but why would SIGQUIT handler need full
elog()? How about we export minimal log-writing function and make
that signal-safe - that is, drop message if already active. This
will excange potential crash/deadlock with lost msg which seems
slightly better behaviour.
--
marko
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-12 20:58:05 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
Previous Message | Peter Eisentraut | 2009-11-12 20:01:26 | Re: recovery is stuck when children are not processing SIGQUIT from previous crash |
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2009-11-12 20:39:48 | Re: EOL for 7.4? |
Previous Message | Bernd Helmle | 2009-11-12 20:35:17 | Re: EOL for 7.4? |