Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Date: 2010-11-23 21:16:37
Message-ID: AANLkTimM50fAukjW6-CEJN2ebAkf6zktfxFWB=X5mrz6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 23, 2010 at 15:02, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:
>>> However, I am not clear what benefit we get from moving this into core
>>> in 9.1.  If it's still going to require a full postmaster restart, the
>>> GUC you have to change may as well be shared_preload_libraries as a
>>> new one.
>
> There's no reason it should require a postmaster restart. New backends
> spawned after the handler is turned on would enable it, and existing
> backends could be signalled to enable it as well.

I think that came off my comment that we could store the on/off in the
startup shared memory block. It'd then be the only way to get it into
any existing backends.

>> on-by-default is what we gain. I think that's fairly big...
>
> More than that. If a crash handler is in core, then:
>
> - It can be inited much earlier, catching crashes that happen during loading
> of libraries and during later backend init; and

Yeah.

> - It's basically free when the cost of shared library loading is removed, so
> it can be left on in production or even be on by default. I need to do some
> testing on this, but given the apparently near-zero cost of initing the
> handler I won't be surprised if testing a GUC to see if the handler should
> be on or not costs more than loading it does.

I'm fairly certain it does. The GUC would be there to be able to turn
the whole thing off because you don't want the dumps, not for
performance reasons.

> I still wouldn't support on-by-default because you'd need an automatic
> process to weed out old crash dumps or limit the number stored. That's a
> bigger job. So I think the admin should have to turn it on, but it'd be good
> to make it easy to turn on in production without a restart; I don't see why
> that'd be hard.

I think the admin should deal with that - just like the admin has to
clear out the old logs.

> I'll try to put together a patch that does just that, time permitting.
> Things are kind of hectic ATM.

Let me know if you want me to look at adapting the patch for that - i
can do that if you prefer.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-11-23 21:18:23 Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Previous Message Kevin Grittner 2010-11-23 20:59:44 Re: Horizontal Write Scaling