On 15/06/2011 2:37 AM, Radosław Smogura wrote:
Hello,
Because, I work a little bit on streaming protocol and from time to time
I have crashes. I want ask if you wont crash reporting (this is one of
minors products from mmap playing) those what I have there is mmaped
areas, and call stacks, and some other stuff.
Core files already contain all that, don't they? They omit shared memory
segments by default on most platforms, but should otherwise be quite
complete.
The usual approach on UNIXes and linux is to use the built-in OS
features to generate a core dump of a crashing process then analyze it
after the fact. That way the crash is over as fast as possible and you
can get services back up and running before spending the time, CPU and
I/O required to analyze the core dump.
This based reports works
for Linux with gdb, but there is some pluggable architecture, which
connects with segfault
Which process does the debugging? Does the crashing process fork() a
copy of gdb to debug its self?
One thing I've been interested in is giving the postmaster (or more
likely a helper for the postmaster) the ability to handle "backend is
crashing" messages, attach a debugger to the crashing backend and
generate a dump and/or backtrace. This might be workable in cases where
in-process debugging can't be done due to a smashed stack, full heap
causing malloc() failure, etc.
--
Craig Ringer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
