Craig Ringer wrote: > On 4/10/2010 8:06 PM, Andrew Dunstan wrote: > > > > > > On 10/04/2010 07:50 AM, Craig Ringer wrote: > >> > >> - If the crash dump handler is enabled by setting the GUC, > >> all backends register the handler during startup or (if it > >> proves practical) when the GUC is changed. > >> > >> - When the handler is triggered by the OS trapping an unhandled > >> exception, it loads dbghelp.dll, writes the appropriate dump > >> format to the hardcoded path, and terminates the process. > >> > >> > > > > What is the performance impact of doing that? Specifically, how does it > > affect backend startup time? > > Without testing I can't say for sure. > > My expection based on how the handler works would be: near-zero, about > as expensive as registering a signal handler, plus the cost of reading > the GUC and doing one string compare to test the value. When disabled, > it's just the GUC test. > > Is there a better mechanism to use for features that're going to be > unused the great majority of the time? Perhaps something that does > require a server restart, but doesn't have any cost at all when disabled?
We definately had trouble producing crash dumps caused by the 128 return code problem, so I can see great value in this, if it can be done simply. I wonder if the 128-exit would have produced a crash file. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
