Re: Crash dumps - Mailing list pgsql-hackers

From Radosław Smogura
Subject Re: Crash dumps
Date
Msg-id 201107041847.34583.rsmogura@softperience.eu
Whole thread Raw
In response to Re: Crash dumps  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Crash dumps
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> Monday 04 of July 2011 16:32:32
> Craig Ringer <craig@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
I asked about crash reports becaus of at this time there was thread about 
crashing in live system.

There is one win, I think, users will faster send crash report, then core dump 
(from many reasons, size, number of confidential information, etc).

Such report may be quite usefull, for "reasonable" bug finding.

It may be attached as contrib too, but I noticed and we agree that report 
generation should not affect speed of shoutdown.

PostgreSQL will look better - server application that generates crash reports 
looks better then no generating. Just a bit of marketing ;)

Regards,
Radek.


pgsql-hackers by date:

Previous
From: Marios Vodas
Date:
Subject: Re: Perl 5.8 requirement for compiling on windows?
Next
From: "Jaime Casanova"
Date:
Subject: Re: keepalives_* parameters usefullness