Added to TODO:
* Add GUC variable to run a command on database panic or
smart/fast/immediate shutdown
---
Peter Eisentraut wrote:
> Martijn van Oosterhout wrote:
> > 3. Add either a GUC or a command line s
What about the Google Core Dumper? :)
http://sourceforge.net/projects/goog-coredumper/
Chris
Peter Eisentraut wrote:
Martijn van Oosterhout wrote:
3. Add either a GUC or a command line switch or PGOPTION switch to
automatically invoke and attach gdb on certain types of error.
Obviously you
On Tue, Nov 01, 2005 at 12:33:39PM +0100, Peter Eisentraut wrote:
> Martijn van Oosterhout wrote:
> > 3. Add either a GUC or a command line switch or PGOPTION switch to
> > automatically invoke and attach gdb on certain types of error.
> > Obviously you can only do this where stdin, stdout and std
Martijn van Oosterhout wrote:
> 3. Add either a GUC or a command line switch or PGOPTION switch to
> automatically invoke and attach gdb on certain types of error.
> Obviously you can only do this where stdin, stdout and stderr have
> not been redirected.
Samba has a configuration parameter that
On Thu, Oct 27, 2005 at 11:44:24AM -0500, Jim C. Nasby wrote:
> > The second option would help us where users are stymied by the system
> > trying to change the core size ulimit, why not make it easier?
>
> It would also be very good if there was a way to verify that the backend
> should be able t
On Thu, Oct 27, 2005 at 07:20:57PM +0200, Martijn van Oosterhout wrote:
> On Thu, Oct 27, 2005 at 01:13:37PM -0400, Douglas McNaught wrote:
> > "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >
> > >It would also be useful to be able to force the backend to
> > > dump core so you can see
On Thu, Oct 27, 2005 at 01:13:37PM -0400, Douglas McNaught wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>
> >It would also be useful to be able to force the backend to
> > dump core so you can see if it's actually working (granted, I know you
> > can end up hitting the ulimit de
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>It would also be useful to be able to force the backend to
> dump core so you can see if it's actually working (granted, I know you
> can end up hitting the ulimit depending on how much memory is being
> consumed). Maybe there is a way to do
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> It would also be useful to be able to force the backend to
> dump core so you can see if it's actually working
kill -ABRT backend-PID
regards, tom lane
---(end of broadcast)---
TI
On Thu, Oct 27, 2005 at 05:11:41PM +0200, Martijn van Oosterhout wrote:
> On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
> > Martijn van Oosterhout writes:
> > > 1. Move the test for strange memory alloc sizes to the palloc macros so
> > > that on error, it points at the palloc call rat
Tom Lane wrote:
Both of these presume you have a programmer running the database, or at
least someone who's not scared of gdb.
I think you have the set relationship the wrong way around ;-)
Personally, I only use gdb in extremis, and I am sure the average DBA
w
On Thu, Oct 27, 2005 at 10:41:08AM -0400, Tom Lane wrote:
> Martijn van Oosterhout writes:
> > 1. Move the test for strange memory alloc sizes to the palloc macros so
> > that on error, it points at the palloc call rather than mcxt.c.
>
> What would that accomplish other than bloating the backend
Martijn van Oosterhout writes:
> 1. Move the test for strange memory alloc sizes to the palloc macros so
> that on error, it points at the palloc call rather than mcxt.c.
What would that accomplish other than bloating the backend? We can't do
it anyway, because of double-evaluation risk.
> 2. A
1. Move the test for strange memory alloc sizes to the palloc macros so
that on error, it points at the palloc call rather than mcxt.c.
Sure, it only attacks a small set of problems, but still.
2. Add either a GUC or a command line switch or PGOPTION switch to call
setrlimit to set the core size
14 matches
Mail list logo
