Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)

>> However, I am not clear what benefit we get from moving this into core
>> in 9.1. If it's still going to require a full postmaster restart, the
>> GUC you have to change may as well be shared_preload_libraries as a
>> new one.

There's no reason it should require a postmaster restart. New backends
spawned after the handler is turned on would enable it, and existing
backends could be signalled to enable it as well.

> on-by-default is what we gain. I think that's fairly big...

More than that. If a crash handler is in core, then:

- It can be inited much earlier, catching crashes that happen during
loading of libraries and during later backend init; and

- It's basically free when the cost of shared library loading is
removed, so it can be left on in production or even be on by default. I
need to do some testing on this, but given the apparently near-zero cost
of initing the handler I won't be surprised if testing a GUC to see if
the handler should be on or not costs more than loading it does.

I still wouldn't support on-by-default because you'd need an automatic
process to weed out old crash dumps or limit the number stored. That's a
bigger job. So I think the admin should have to turn it on, but it'd be
good to make it easy to turn on in production without a restart; I don't
see why that'd be hard.

I'll try to put together a patch that does just that, time permitting.
Things are kind of hectic ATM.

--
Craig Ringer