Craig Ringer <cr...@postnewspapers.com.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
