Skip site navigation (1) Skip section navigation (2)

Re: C set return function differences on 8.0?

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tim Jackson <tim(dot)jackson(at)ints(dot)com>
Cc: pgsql-interfaces(at)postgresql(dot)org
Subject: Re: C set return function differences on 8.0?
Date: 2005-07-09 01:58:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-interfaces
[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

In response to


pgsql-interfaces by date

Next:From: Tom LaneDate: 2005-07-09 02:13:23
Subject: Re: C set return function differences on 8.0?
Previous:From: Michael FuhrDate: 2005-07-08 15:23:39
Subject: Re: C set return function differences on 8.0?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group