Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Date
Msg-id AANLkTik1rTxoMGEkZCuKgkThqRGiBsSmi9sekdL=H3XG@mail.gmail.com
Whole thread Raw
In response to Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
List pgsql-hackers
On Mon, Nov 22, 2010 at 18:46, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> * 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.  Which would have a number
> of advantages, not least that you don't need to have the crash dumper
> dependent on GUC working.  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.

No, it's dependent on close to zero backend functionality.
Particularly if we take out the dependency on elog() (write_stderr is
much simpler). In fact, the calls to elog() are the *only* places
where it calls into the backend as it stands today.

And yes, ISTM it could work reasonably well to use the
creation/deletion of the directory as an on/off switch for it. Which
is the default is of course up to the packager then as well ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: format() with embedded to_char() formatter
Next
From: Magnus Hagander
Date:
Subject: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)