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