On 11/23/2010 01:46 AM, Tom Lane wrote:
* However, when storing it in crashdumps, I think the code would need
to create that directory if it does not exist, doesn't it?
If it didn't do so, then manual creation/removal of the directory could
be used as an on/off switch for the feature.
Yep. That's how I'd want to do it in 9.1 - test for the directory and
use that to decide whether to set the handler during early backend
startup. That way you don't need a GUC, and should be able to load it
*very* early in backend startup.
I haven't looked at the patch but this
discussion makes it sound like the dumper is dependent on an
uncomfortably large amount of backend code being functional. You need
to minimize the number of assumptions of that sort.
It doesn't need to have any backend code working, really; all it needs
is a usable stack and the ability to allocate off the heap. It won't
save you in total OOM situations, stack exhaustion, or severe stack
corruption, but should work pretty much any other time.
The crash dump facility in dbghelp.dll offers *optional* features where
apps can stream in additional app-specific data like recent log
excerpts, etc. I didn't try to implement anything like that in the
initial module partly because I want to minimize the amount of the
backend that must be working for a crash dump to succeed.
--
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
