Re: Ideas for easier debugging of backend problems

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: Ideas for easier debugging of backend problems
Дата
Msg-id 20051027151141.GK4259@svana.org
обсуждение исходный текст
Ответ на Re: Ideas for easier debugging of backend problems  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Ideas for easier debugging of backend problems  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список pgsql-hackers
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.

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?

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Ideas for easier debugging of backend problems
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: ERROR: invalid memory alloc request size