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 20051108202925.124bbed5@thunder.logicalchaos.org
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
List pgsql-hackers
When grilled further on (Tue, 08 Nov 2005 11:12:04 -0500),
Tom Lane <tgl@sss.pgh.pa.us> confessed:

> 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?
>

Strings on pg_sphere.so does contain /usr/local/pgsql810/lib.

I've attached a small dump file that when I create an index on the table, it fails.  It works on 225 entries, but
failedon 250.  Don't know if this is data dependent or size.  Is that a page boundary?  It seems to me that unless the
right/leftstuff doesn't come into play for all indexes, that stuff is built correctly. 

Dump command:
/usr/local/pgsql810/bin/pg_dump -F c -p 5433 -d tassiv -t test_data -f index_problem.dump

Created the table and index by:
tassiv=# SELECT loc into test_data from catalog limit 250;
tassiv=# create index test_data_index on test_data using gist( loc );
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

tassiv=# \d test_data
  Table "public.test_data"
 Column |  Type  | Modifiers
--------+--------+-----------
 loc    | spoint |

Cheers,
Rob

--
 19:51:58 up 37 days, 12:26,  6 users,  load average: 2.15, 2.39, 2.41
Linux 2.6.5-02 #8 SMP Mon Jul 12 21:34:44 MDT 2004

Attachment

pgsql-hackers by date:

Previous
From: daveg
Date:
Subject: Re: Exclusive lock for database rename
Next
From: Gayathri TK
Date:
Subject: Accessing libq functions from UDF (shared library)