Re: SIGSEGV taken on 8.1 during dump/reload - Mailing list pgsql-hackers

From Robert Creager
Subject Re: SIGSEGV taken on 8.1 during dump/reload
Date
Msg-id 20051108115854.00002a10@C118181.stortek.com
Whole thread Raw
In response to Re: SIGSEGV taken on 8.1 during dump/reload  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SIGSEGV taken on 8.1 during dump/reload  (Teodor Sigaev <teodor@sigaev.ru>)
List pgsql-hackers
On Tue, 08 Nov 2005 11:12:04 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Teodor Sigaev <teodor@sigaev.ru> writes:
> > Layout of GIST_SPLITVEC struct has been changed from 8.0, I'm afraid that
> > old .so is used.  spl_(right|left)valid fields was added to GIST_SPLITVEC.
> 
> Does look a bit suspicious ... Robert, are you *sure* you've got the
> right version of pgsphere linked in?  Did you compile it against the
> right set of Postgres header files?
> 

I copied pg_sphere into the contrib directory in 8.1.0, which is where it was
built.  Last night, I executed a <make clean> from contrib/pg_sphere, re-built
<make> and re-installed.  I checked the pg_sphere Makefile, and it references
local, not absolute paths.

So, I'm as sure as I can be right now.  How can I check the .so files installed
by the build?  Do they reference an absolute path for their dependent .so files
(postgres), or will they use ld.so.conf, which might then explain the problem. 
My ld.so.conf still points to the 8.0.2 version, as I've not switched yet to
8.1.0.

In any case, why would the <make installcheck> work in the pg_sphere directory? 
That would have to use the installed libraries.  I don't have the sources with
me, but I'd think an index would of been created on a spoint column, but maybe
not?

Cheers,
Rob


pgsql-hackers by date:

Previous
From: shenanigans
Date:
Subject: [OTAnn] Feedback
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Assert failure found in 8.1RC1