Обсуждение: Postgres dies when using an intarray operator

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

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

[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

Michael Fuhr <mike@fuhr.org> 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

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: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/