Re: Proposed Windows-specific change: Enable crash dumps (like core files)
От | Craig Ringer |
---|---|
Тема | Re: Proposed Windows-specific change: Enable crash dumps (like core files) |
Дата | |
Msg-id | 4CA9C40E.5070205@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: Proposed Windows-specific change: Enable crash dumps (like core files) (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Proposed Windows-specific change: Enable crash
dumps (like core files)
|
Список | pgsql-hackers |
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? -- Craig Ringer Tech-related writing at http://soapyfrogs.blogspot.com/
В списке pgsql-hackers по дате отправления: