Re: recovery is stuck when children are not processing SIGQUIT from previous crash
Marko Kreen <markokr@gmail.com>
From: Marko Kreen <markokr@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, pgsql-admin@postgresql.org
Date: 2009-11-12T20:37:03Z
Lists: pgsql-hackers
On 11/12/09, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Marko Kreen <markokr@gmail.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