Date: Fri, 8 Jul 2005 19:58:00 -0600
From: Michael Fuhr <mike@fuhr.org>
To: Tim Jackson <tim.jackson@ints.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: C set return function differences on 8.0?
Message-ID: <20050709015800.GA11641@winnie.fuhr.org>
References: <42CDCFB4.2030908@ints.com>
	<20050708152339.GA81341@winnie.fuhr.org>
	<42CF168A.4080007@ints.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42CF168A.4080007@ints.com>

[Please copy the mailing list on replies so others can contribute
to and learn from the discussion.]

On Fri, Jul 08, 2005 at 05:12:58PM -0700, Tim Jackson wrote:
> Michael Fuhr wrote:
> > What do you mean by "abort" -- does the backend crash?  If so, and
> > if you get a core dump, then it might be useful to see a stack trace.
> >
> 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?  If one was made then it'll
probably be somewhere under $PGDATA (e.g., $PGDATA/base/XXX/core)
unless your system is configured to put core dumps elsewhere.

If there isn't a core dump then you could add some debugging ereport()
calls to your code so you can find out where the crash is happening.
Another possibility might be to attach a debugger to the backend.

> >Could you post a simple, self-contained test case that works in 7.4
> >and fails in 8.0?  That is, all SQL, C code, and data that somebody
> >
> The problem I have is we are using a licensed library to accesss the 
> target database.  We have c code which parses SQLSRF and makes a call to 
> these 3rd party lib functions which returns strings of data.

So your C function calls these library functions, which query some
other data source and return strings back to you, right?  How are
these strings returned -- as char * values?  Can you at least post
your code?

> Today we tried to just hard code some data strings and pass that into 
> SRF part of the code.  We put in values that we expected to cause the 
> problem and it did not cause the problem.  So we are stuck with how to 
> proceed.

Let's see if attaching a debugger to the backend or adding some
ereport() calls can at least tell us where the crash is happening.
Then maybe we can figure out why.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/