Re: SIGSEGV taken on 8.1 during dump/reload

Поиск
Список
Период
Сортировка
От Robert Creager
Тема Re: SIGSEGV taken on 8.1 during dump/reload
Дата
Msg-id 20051108115854.00002a10@C118181.stortek.com
обсуждение исходный текст
Ответ на Re: SIGSEGV taken on 8.1 during dump/reload  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: SIGSEGV taken on 8.1 during dump/reload  (Teodor Sigaev <teodor@sigaev.ru>)
Список 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 по дате отправления:

Предыдущее
От: shenanigans
Дата:
Сообщение: [OTAnn] Feedback
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Assert failure found in 8.1RC1