Re: Is *that* why debugging backend startup is so hard!? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is *that* why debugging backend startup is so hard!?
Date
Msg-id 11209.962139949@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is *that* why debugging backend startup is so hard!?  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Big 7.1 open items
Next
From: Bruce Momjian
Date:
Subject: Re: Big 7.1 open items