Ideas for easier debugging of backend problems

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 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.

However, for this to be useful we need to distinguish between
"internal" errors (like palloc) and user errors (like tablename not
found). There doesn't appear to be a way to distinguish them.

Mind you, distinguishing the errors would be useful, say adding
err_internal() to the ones that are not supposed to happen and can be
fixed (i.e. not disk errors). We could than add a standard message
about "Please report this as a bug".

Still something like:

if( isatty(0) && isatty(1) && isatty(2) )
if( fork() != 0 ) /* Parent */
{
while(1) pause();
}
else
{
/* Imagine sprintf calls here */
exec("gdb", "/proc/$ppid/exec", $ppid)
_exit(); /* Oops */
}

Might be useful for getting bug reports out of people who can't work
out how to get corefiles...

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)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.