Return-Path: pg_adm@postgres.berkeley.edu Received: by postgres.Berkeley.EDU (5.61/1.29) id AA03604; Wed, 2 Jun 93 17:20:39 -0700 Date: Wed, 2 Jun 93 17:20:39 -0700 From: "David J. Hughes" Subject: Re: Help!!! Backend core dump To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu To: "Paul M. Aoki" Cc: postgres@postgres.Berkeley.EDU In-Reply-To: <9306021713.AA29906@postgres.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Jun 1993, Paul M. Aoki wrote: > these so-helpful messages are indeed the libpq way of telling > you the backend dumped core. :-/ that's about all it can tell > you, too -- there's garbage in the fd. > > a general point for everyone: when submitting bug reports, it's > important to send a stack trace from *the backend core*. when > the backend barfs, it leaves a core in its working directory > ($PGDATA/base/); the output of the command > "where" given to either > dbx `which postgres` core > or > gdb `which postgres` core > is what i'm talking about. I would if I could but I can't so I won't. In short, there is no core dump in $PGDATA/base/. The only core dump is found in the working directory of the libpq based client code talking to the unfriendly back-end. > if you fire up the postmaster with the -d option, it will spew > all of the backend output onto the postmaster's controlling tty. > seeing what the backend's last dying words were can also help > us a lot. I will forward some debug output and test data/queries etc. to you. bambi ___ David J. Hughes bambi@Bond.edu.au / \ / / / / __/ __ __ ____/ / / __ Senior Network Programmer / \ / \ / \ / / / / / \ / Comms Development & Operation \____/ \__// / \__/ \___/ / / / Qld. 4229 AUSTRALIA (+61 75 951450)