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 по дате отправления:

Предыдущее
От: Chris Bitmead
Дата:
Сообщение: Re: C exception code
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Makefile for parser