Re: Ideas for easier debugging of backend problems - Mailing list pgsql-hackers

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 <kleptog@svana.org> 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.
> 
> The double-evaluation is avoidable (on GCC at least). I was thinking
> about when you --enable-cassert or something. But you're right, the
> test in palloc is always on, so you don't save much.
> 
> > > 2. Add either a GUC or a command line switch or PGOPTION switch to call
> > > setrlimit to set the core size to something bigger. Most places only
> > > soft limit the core size, not hard limit.
> > 
> > > 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.
> > 
> > Both of these presume you have a programmer running the database, or at
> > least someone who's not scared of gdb.
> 
> I've been thinking more along the lines that gdb is scriptable. We
> could invoke gdb in a way that immediatly dumps a backtrace, the local
> variables and some of the globals to a file and display a message to
> the user: please attach this to your bug report...
> 
> Like today, having all this info upfront would save some time, because
> then we wouldn't have to teach people how to use gdb or what variables
> are important. Ofcourse, we'd really need to distinguish between
> run-of-the-mill errors and actual serious problems.

Perhaps have a flag that people can turn on when they're having issues?
Still get a good amount of bloat, but at least not all the time...

> 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 to generate a core, such as being able to see what
ulimits the backend is running under. This would have saved me some pain
yesterday. 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 this already and I just don't know
it...
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461