Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Ideas for easier debugging of backend problems


  • 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: Thu, 27 Oct 2005 10:41:08 -0400
  • Message-id: <18946(dot)1130424068(at)sss(dot)pgh(dot)pa(dot)us>

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



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group