To: Michael Fuhr <mike@fuhr.org>
Cc: Tim Jackson <tim.jackson@ints.com>,
	pgsql-interfaces@postgresql.org
Subject: Re: C set return function differences on 8.0? 
In-reply-to: <20050709015800.GA11641@winnie.fuhr.org> 
References: <42CDCFB4.2030908@ints.com>
	<20050708152339.GA81341@winnie.fuhr.org>
	<42CF168A.4080007@ints.com>
	<20050709015800.GA11641@winnie.fuhr.org>
Comments: In-reply-to Michael Fuhr <mike@fuhr.org>
	message dated "Fri, 08 Jul 2005 19:58:00 -0600"
Date: Fri, 08 Jul 2005 22:13:23 -0400
Message-ID: <331.1120875203@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Michael Fuhr <mike@fuhr.org> writes:
> On Fri, Jul 08, 2005 at 05:12:58PM -0700, Tim Jackson wrote:
>> The backend crashes, in pgadmin  attempting to display the view simple 
>> says aborting.  There is no core dump, and the log only seems to reflect 
>> the standard
>> WARNING:  terminating connection because of crash of another server process

> Where did you look for a core dump?

"There is no core dump" is not an acceptable answer: if there isn't one,
the first item on your agenda must be to get one (or else run the
problem case under gdb so you don't need a dump to get a stack trace).

Usually if there's no dump it's because the default configuration on
your system is "ulimit -c 0" to suppress core dumps from daemons.
Put "ulimit -c unlimited" (or local equivalent) into your postmaster
start script and restart the postmaster.

On the whole though I'd recommend learning how to attach gdb to a live
backend, since then not only can you get a stack trace from the point of
the fault, but you can then work backwards by setting breakpoints ahead
of the crash and stepping through the code to see where it goes wrong.

			regards, tom lane