On 5/07/2011 9:05 PM, Magnus Hagander wrote:
> On Tue, Jul 5, 2011 at 15:02, Robert Haas<robertmhaas@gmail.com> wrote:
>> On Mon, Jul 4, 2011 at 12:47 PM, Radosław Smogura
>> <rsmogura@softperience.eu> wrote:
>>> I asked about crash reports becaus of at this time there was thread about
>>> crashing in live system.
>>
>> Yeah, I thought this was the result of that effort:
[snip]
> That crash dump is basically the windows equivalent of a coredump,
> though. Just a different name...
Yup, it's a cut-down core dump. In this case generated in-process by
the crashing backend.
It'd be nice to be able to generate the crash dump from out-of-process.
Unfortunately, the automatic crash dump generation system on Windows
doesn't appear to be available to system services running
non-interactively. Not that I could see, anyway. As a result we had to
trap the crashes within the crashing process and generate the dump from
there. As previously stated, doing anything within a segfaulting process
is unreliable, so it's not the best approach in the world.
All I was saying in this thread is that it'd be nice to have a way for a
crashing backend to request that another process capture diagnostic
information from it before it exits with a fault, so it doesn't have to
try to dump its self.
As Tom said, though, anything like that is more likely to decrease the
reliability of the overall system. You don't want a dead backend hanging
around forever waiting for the postmaster to act on it, and you *really*
don't want other backends still alive and potentially writing from shm
that's in in who-knows-what state while the postmaster is busy fiddling
with a crashed backend.
So, overall, I think "dump a simple core and die as quickly as possible"
is the best option. That's how it already works on UNIX, and all the
win32 crash dump patches do is make it work on Windows too.
--
Craig Ringer
POST Newspapers
276 Onslow Rd, Shenton Park
Ph: 08 9381 3088 Fax: 08 9388 2258
ABN: 50 008 917 717
http://www.postnewspapers.com.au/