Re: Crash dumps

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Radosław Smogura <rsmogura(at)softperience(dot)eu>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Crash dumps
Date: 2011-07-04 14:32:32
Message-ID: 24287.1309789952@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> Why not produce a tool that watches the datadir for core files and
> processes them? ...

By and large, our attitude has been that Postgres shouldn't be crashing
often enough to make this sort of infrastructure worthwhile. Developer
time spent on it would be far better spent on fixing the bugs instead.

> For that reason, it'd be handy if a backend could trap SIGSEGV and
> reliably tell the postmaster "I'm crashing!" so the postmaster could
> fork a helper to capture any additional info the backend needs to be
> alive for. ...
> Unfortunately, "reliably" and "segfault" don't go together.

Yeah. I think there's no chance at all that we'd accept patches pointed
in this direction. They'd be more likely to decrease the system's
reliability than anything else. Aside from the difficulty of doing
anything at all reliably in an already-failing process, once we realize
that something is badly wrong it's important to kill off all other
backends ASAP. That reduces the window for any possible corruption of
shared memory to make it into on-disk state. So interposing a "helper"
to fool around with the failed process doesn't sound good at all.

In practice I think you can generally get everything of interest
out of the core file, so it's not clear to me that there's any win
available from this line of thought anyhow.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Gould 2011-07-04 14:57:57 Problem installing odbc and .Net drivers on Windows 7 64 Ultimate
Previous Message Magnus Hagander 2011-07-04 14:09:00 Re: non-superuser reserved connections? connection pools?