Return-Path: aoki Received: by postgres.Berkeley.EDU (5.61/1.29) id AA29906; Wed, 2 Jun 93 10:13:15 -0700 Message-Id: <9306021713.AA29906@postgres.Berkeley.EDU> From: aoki@postgres.berkeley.edu (Paul M. Aoki) Subject: Re: Help!!! Backend core dump To: postgres@postgres.berkeley.edu Sender: pg_adm@postgres.berkeley.edu In-Reply-To: Your message of Wed, 2 Jun 93 00:48:23 -0700 Date: Wed, 02 Jun 93 10:12:55 -0700 Sender: aoki@postgres.Berkeley.EDU X-Mts: smtp "David J. Hughes" writes: > Error: Unexpected response from the backend, exiting... > Error: Unexpected identfier in dump_data: I > Error: Unexpected identfier in dump_data: P > with the same result (ie. a core dump) 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. and as with any other bug report, enclosing a (minimally-sized) data set/schema description/set of queries that reproduces the problem will also bump the priority up considerably. (for example, when the ultrix 4.3 shmat() bug hit us, we had to provide a 4-line program that reproduced the problem before DEC would look at the SPR. saying "shmat loses when called with an OMAGIC file and these arguments" was not enough.) the reason for this is pretty obvious. if you don't boil it down to something anyone can reproduce, then you've just reduced the number of people who have the *slightest* chance of fixing the bug from "anyone who can run a debugger and read C" to "4-star gurus who have all 250,000 lines of code memorized". 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. -- Paul M. Aoki | CS Div., Dept. of EECS, UCB | aoki@postgres.Berkeley.EDU | Berkeley, CA 94720 | ...!uunet!ucbvax!aoki