Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
От | Magnus Hagander |
---|---|
Тема | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) |
Дата | |
Msg-id | AANLkTik1rTxoMGEkZCuKgkThqRGiBsSmi9sekdL=H3XG@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
|
Список | 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 по дате отправления: