Re: [HACKERS] Postgres dies when using an intarray operator

2006-04-03 Thread Teodor Sigaev 

Fixed in cvs for 7.4-8.2 releases.

Michael Fuhr wrote:

On Sat, Apr 01, 2006 at 03:40:19PM +0200, jeroen van iddekinge wrote:

When using intarray operator in a query, postgres dies and restart
itself when executing  the following query:

select r1.bet_sentence  r2.bet_sentence
from related r1,related r2
where r1.bet_sentence  r2.bet_sentence


Here's a complete test case:

CREATE TABLE foo (a integer[]);

INSERT INTO foo (a)
  SELECT array[random() * 10, random() * 10, random() * 10]
  FROM generate_series(1, 24);

CREATE INDEX foo_a_idx ON foo USING gist (a gist__int_ops);

SET enable_seqscan TO off;
SELECT f1.a  f2.a FROM foo f1, foo f2 WHERE f1.a  f2.a;

This crashes for me in 8.1.3 on FreeBSD 6.1-PRERELEASE and Solaris 9.
An assert-enabled 8.1.3 logs the following:

TRAP: BadArgument(!(((header-context) != ((void *)0)  
(Node*)((header-context)))-type) == T_AllocSetContext, File: mcxt.c, Line: 612)



--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

[HACKERS] Postgres dies when using an intarray operator

2006-04-01 Thread jeroen van iddekinge 
Hi all,


When using intarray operator in a query, postgres dies and restart
itself when executing  the following query:


select r1.bet_sentence  r2.bet_sentence
from related r1,related r2
where r1.bet_sentence  r2.bet_sentence

the log file contains the following:

LOG:  server process (PID 14283) was terminated by signal 11
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted at 2006-04-01 15:07:04 CEST
LOG:  checkpoint record is at 1/E9178B1C
This is the only information I can find

'related' has the following definition:

Column|  Type  | Modifiers
--++---
 id   | integer| not null
 id_line  | integer|
 id_linegroup | integer|
 id_word_1| integer|
 id_word_2| integer|
 rtype| character varying(100) |
 bet_sentence | integer[]  |
there are about 100 000 records in this table.


The crash only happends when I create the gist index on bet_sentence:

create index ind_related_7 on related using gist ( bet_sentence gist__int_ops);


Using unbuntu 5.1 ,postgres version 8.1.3,compiled from source and intarray 
installed

Can someone explain this crash?


Thanks 

Jeroen


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Postgres dies when using an intarray operator

2006-04-01 Thread Michael Fuhr 
On Sat, Apr 01, 2006 at 03:40:19PM +0200, jeroen van iddekinge wrote:
 When using intarray operator in a query, postgres dies and restart
 itself when executing  the following query:
 
 select r1.bet_sentence  r2.bet_sentence
 from related r1,related r2
 where r1.bet_sentence  r2.bet_sentence

Here's a complete test case:

CREATE TABLE foo (a integer[]);

INSERT INTO foo (a)
  SELECT array[random() * 10, random() * 10, random() * 10]
  FROM generate_series(1, 24);

CREATE INDEX foo_a_idx ON foo USING gist (a gist__int_ops);

SET enable_seqscan TO off;
SELECT f1.a  f2.a FROM foo f1, foo f2 WHERE f1.a  f2.a;

This crashes for me in 8.1.3 on FreeBSD 6.1-PRERELEASE and Solaris 9.
An assert-enabled 8.1.3 logs the following:

TRAP: BadArgument(!(((header-context) != ((void *)0)  
(Node*)((header-context)))-type) == T_AllocSetContext, File: 
mcxt.c, Line: 612)

-- 
Michael Fuhr

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Postgres dies when using an intarray operator

2006-04-01 Thread Michael Fuhr 
[Please copy the mailing list on replies.]

On Sat, Apr 01, 2006 at 07:20:57PM +0200, jeroen van iddekinge wrote:
  TRAP: BadArgument(!(((header-context) != ((void *)0)  
  (Node*)((header-context)))-type) == T_AllocSetContext, File: 
  mcxt.c, Line: 612)
  
 
 I started the postmaster with -d 5 but I didn't get something like
 above, only a signal 11 message.
 How can I get more information from a crash?

The above error would be logged only if the server was built with
assertions enabled.  See the documentation for the --enable-cassert
configure option:

http://www.postgresql.org/docs/8.1/interactive/install-procedure.html

If the server was built with debugging symbols (--enable-debug)
then you could obtain useful information from a core dump by using
a debugger like gdb to display a stack trace.  To see examples
search the archives for words like gdb and stack trace

-- 
Michael Fuhr

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Postgres dies when using an intarray operator

2006-04-01 Thread Tom Lane 
Michael Fuhr [EMAIL PROTECTED] writes:
 Here's a complete test case:

 CREATE TABLE foo (a integer[]);

 INSERT INTO foo (a)
   SELECT array[random() * 10, random() * 10, random() * 10]
   FROM generate_series(1, 24);

 CREATE INDEX foo_a_idx ON foo USING gist (a gist__int_ops);

 SET enable_seqscan TO off;
 SELECT f1.a  f2.a FROM foo f1, foo f2 WHERE f1.a  f2.a;

This seems to bear out the concern expressed at _int_gist.c line 44:

/* XXX are we sure it's safe to scribble on the query object here? */

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings