From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Ideas for easier debugging of backend problems |
Date: | 2005-10-27 14:41:08 |
Message-ID: | 18946.1130424068@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2005-10-27 15:11:41 | Re: Ideas for easier debugging of backend problems |
Previous Message | Martijn van Oosterhout | 2005-10-27 14:34:48 | Re: ERROR: invalid memory alloc request size <a_big_number_here> |