Re: Is *that* why debugging backend startup is so hard!?
От | Giles Lean |
---|---|
Тема | Re: Is *that* why debugging backend startup is so hard!? |
Дата | |
Msg-id | 2118.962094446@nemeton.com.au обсуждение исходный текст |
Ответ на | Is *that* why debugging backend startup is so hard!? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> Needless to say I find this braindead in the extreme. Wow, definitely braindead. Trapping some of them on systems that can programmatically generate a stack backtrace might be useful -- it would help reporting what happened. Blocking them and continuing seems about the most dangerous thing that could be done; if we've just got SIGSEGV or similar the code is confused isn't to be trusted to safely modify data! > Will anyone object if I change the signal masks so that we never > ever block SIGABRT, SIGILL, SIGSEGV, SIGBUS, SIGTRAP, SIGCONT, > SIGSYS? Any other candidates? Are there any systems that do not > define all of these signal names? I'd expect these everywhere; certainly they're all defined in the "Single Unix Specification, version 2". Some of them don't exist in ANSI C, if that matters. Usually it's easy enough to wrap code that cares in #ifdef SIGABRT ... #endif so when/if a platform shows up that lacks one or more it's easy to fix. Potential additions to your list: SIGFPE SIGSTOP (can't be blocked) Regards, Giles
В списке pgsql-hackers по дате отправления: