Skip site navigation (1) Skip section navigation (2)

Re: bitmap scan cause core dump 8.1dev

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>,Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bitmap scan cause core dump 8.1dev
Date: 2005-08-27 15:11:58
Message-ID: 20050827151158.GA60110@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Aug 27, 2005 at 10:28:30AM -0400, Tom Lane wrote:
> Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> > I finally narrow down my problem with postmaster crashing 8.1dev 
> > (today's CVS):
> 
> Can you provide a self-contained test case?  The backtrace is
> interesting but it's not enough information to find the bug.

Here's a simple test case based on what I think Oleg is doing. It
needs tsearch2, and it needs to insert enough records that a bitmap
scan would be chosen (I think).

CREATE TABLE foo (
    t     text,
    tidx  tsvector
);

CREATE INDEX foo_tidx_idx ON foo USING gist (tidx);

CREATE TRIGGER footrig BEFORE INSERT OR UPDATE ON foo
  FOR EACH ROW EXECUTE PROCEDURE tsearch2('tidx', 't');

INSERT INTO foo (t) SELECT 'test' || x FROM generate_series(1, 3000) AS g(x);

ANALYZE foo;

SET enable_bitmapscan TO off;
SELECT t FROM foo, to_tsquery('test1') AS query WHERE tidx @@ query;
   t   
-------
 test1
(1 row)

SET enable_bitmapscan TO on;
SELECT t FROM foo, to_tsquery('test1') AS query WHERE tidx @@ query;
server closed the connection unexpectedly

My backtrace shows this:

#0  0x00112d14 in ExecEvalVar (exprstate=0x0, econtext=0x415588, isNull=0xffbfe34f "\b", isDone=0x0) at execQual.c:491
491                     Assert(attnum <= tuple_type->natts);
(gdb) bt
#0  0x00112d14 in ExecEvalVar (exprstate=0x0, econtext=0x415588, isNull=0xffbfe34f "\b", isDone=0x0) at execQual.c:491
#1  0x00116128 in ExecEvalExprSwitchContext (expression=0x4154f0, econtext=0x10000, isNull=0xffbfe34f "\b", isDone=0x0)
    at execQual.c:2808
#2  0x0011f75c in ExecIndexEvalRuntimeKeys (econtext=0x4154f0, run_keys=0x415588, scan_keys=0xffbfe34f, n_keys=0)
    at nodeIndexscan.c:270

-- 
Michael Fuhr

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-27 15:26:07
Subject: Re: Call for 7.5 feature completion
Previous:From: Tom LaneDate: 2005-08-27 15:09:09
Subject: Re: Typmod for user-defined types

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group