Received: from mail.xnet.com (quake.xnet.com [198.147.221.67]) by postgresql.org (8.11.3/8.11.1) with ESMTP id f3GKidu85407 for ; Mon, 16 Apr 2001 16:44:40 -0400 (EDT) (envelope-from selkovjr@xnet.com) Received: from selkovjr.xnet.com ([204.248.57.203]) by mail.xnet.com (8.9.3+Sun/XNet-3.0R) with ESMTP id PAA18588; Mon, 16 Apr 2001 15:44:27 -0500 (CDT) Received: from selkovjr.xnet.com (localhost [127.0.0.1]) by selkovjr.xnet.com (8.9.3/8.9.3) with ESMTP id PAA00749; Mon, 16 Apr 2001 15:44:32 -0500 Message-Id: <200104162044.PAA00749@selkovjr.xnet.com> To: Lonnie Cumberland Cc: pgsql-interfaces@postgresql.org From: selkovjr@mcs.anl.gov Reply-to: selkovjr@mcs.anl.gov Subject: Re: backend debug information In-reply-to: <20010416192226.52764.qmail@web12503.mail.yahoo.com> References: <20010416192226.52764.qmail@web12503.mail.yahoo.com> Comments: In-reply-to Lonnie Cumberland message dated "Mon, 16 Apr 2001 12:22:26 -0700." Date: Mon, 16 Apr 2001 15:44:32 -0500 X-Archive-Number: 200104/60 X-Sequence-Number: 1443 Take it easy, Lonnie! I am still working on your earlier question :) > I am getting this: > trdata=# select desdecrypt('a','b'); > pqReadData() -- backend closed the channel unexpectedly. > This probably means the backend terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > !# \q You've probably got a segv. There's very little else that can happen in your code. That in turn could be caused by writing at an overflown pointer or by returning the wrong type. As far as debugging, short of being able to run a postgres under gdb while connecting clients to it (I wish I knew whether that was at all possible), your options are: 1. (preferred) -- fprintf(stderr, ,) from within your code; then watch the logs or simply start your postmaster from a shell without detaching it and see the output. 2. Make a wrapper that walks like a postgres and talks like a postgres but does nothing except it calls your function and checks the return value; then run that stuff in gdb. As a general rule, 3. Slow down. Proceed in small increments. Start with a blank function and make sure you can pass the desired arguments to it. Return nothing. Check the values you pass with fprintf. Then add a return statement and see if you can get away with it. Check it on the outside with a SELECT. After that, keep adding the code in small logical units. If it breaks, insert fprintf's to see where. Fprintfs are almost as good as debugger breakpoints. I'll be back with more stuff regarding the datatypes shortly. --Gene