Re: Is *that* why debugging backend startup is so hard!?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is *that* why debugging backend startup is so hard!?
Дата
Msg-id 11209.962139949@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Is *that* why debugging backend startup is so hard!?  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> I just spent a rather frustrating hour trying to debug a backend startup
>> failure --- and getting nowhere because I couldn't catch the failure in
>> a debugger, or even step to where I thought it might be.  I've seen this
>> sort of difficulty before, and always had to resort to expedients like
>> putting in printf's.  But tonight I finally realized what the problem is.

> Could that be contributing to the Heisenbug I decribed on Sunday in "Pid
> file magically disappears"?

Hm.  Maybe.  I haven't tried to reproduce the pid-file issue here
(I'm up to my eyebrows in memmgr at the moment).  But the blocking
of SEGV and friends could certainly lead to some odd behavior, due
to code plowing on after getting an error that should have crashed it.

Depending on how robust your local implementation of abort(3) is,
it's even possible that the code would fall through a failed
Assert() test...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Big 7.1 open items
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Big 7.1 open items