[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/
