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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Is *that* why debugging backend startup is so hard!?
Date: 2000-06-27 21:05:49
Message-ID: 11209.962139949@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-06-27 21:16:49 Re: Big 7.1 open items
Previous Message Tom Lane 2000-06-27 21:00:11 Re: Big 7.1 open items