Обсуждение: bitmap scan cause core dump 8.1dev

Поиск
Список
Период
Сортировка

bitmap scan cause core dump 8.1dev

От
Oleg Bartunov
Дата:
This message is in MIME format.  The first part should be readable text, while the remaining parts are likely
unreadablewithout MIME-aware tools.
 

---559023410-560155114-1125148906=:16397
Content-Type: TEXT/PLAIN; charset=koi8-r; format=flowed
Content-Transfer-Encoding: 8BIT

Hi there,

I finally narrow down my problem with postmaster crashing 8.1dev 
(today's CVS):

This query works as expected:
# select  name_qualified from place
where fts_index @@ to_tsquery('moscow');

This query (essentially the same as above) crashes:
# select  name_qualified from place, to_tsquery('moscow') as query 
where fts_index @@ query;

When I disable bitmap scanning (set enable_bitmapscan=off)
second query works fine.

gdb output:

#0  ExecEvalVar (exprstate=0x1, econtext=0x0,    isNull=0xbfffe1cb
"\b╟╠<\b╦╡<\b\210╡<\b\bБЪ©Б>\025\b╦╡<\b\210╡<\b<╡<\b\001",isDone=0x0) at execQual.c:486
 
#1  0x0814c345 in ExecEvalExprSwitchContext (expression=0x0, econtext=0x0,    isNull=0x1 <Address 0x1 out of bounds>,
isDone=0x1)at execQual.c:2808
 
#2  0x08155f0e in ExecIndexEvalRuntimeKeys (econtext=0x83cb2b8,    run_keys=0x83cb288, scan_keys=0x83cb23c, n_keys=1)
atnodeIndexscan.c:270
 
#3  0x08153ee2 in ExecBitmapIndexReScan (node=0x83a31c8, exprCtxt=0x1)    at nodeBitmapIndexscan.c:146
#4  0x0814498f in ExecReScan (node=0x83cb1b0, exprCtxt=0x83ca1e8)    at execAmi.c:131
#5  0x081449a6 in ExecReScan (node=0x83ca730, exprCtxt=0x83ca1e8)    at execAmi.c:135
#6  0x08157b6b in ExecNestLoop (node=0x83ca15c) at nodeNestloop.c:163
#7  0x081483cd in ExecProcNode (node=0x83ca15c) at execProcnode.c:350
#8  0x0814698c in ExecutePlan (estate=0x83c9ec4, planstate=0x83ca15c,    operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection,   dest=0x8320fbc) at execMain.c:1107
 
#9  0x08145b0b in ExecutorRun (queryDesc=0x83c99fc,    direction=ForwardScanDirection, count=1) at execMain.c:231
#10 0x08113548 in ExplainOnePlan (queryDesc=0x83c99fc, stmt=0x83b8570,    tstate=0x83cf694) at explain.c:240
#11 0x08113040 in ExplainOneQuery (query=0x83cec44, stmt=0x83b8570,    tstate=0xbfffe3e0) at explain.c:205
#12 0x08112ea2 in ExplainQuery (stmt=0xbfffe3e0, dest=0x1) at explain.c:121
#13 0x081da5b3 in PortalRunUtility (portal=0x83c028c, query=0x83b7ffc,    dest=0x83cebec, completionTag=0x0) at
pquery.c:991
#14 0x081d9ff8 in PortalRun (portal=0x83c028c, count=2147483647,    dest=0x83b85bc, altdest=0x83b85bc,
completionTag=0xbfffe610"")    at pg_list.h:81
 
#15 0x081d5b5b in exec_simple_query (    query_string=0x83b7de4 "explain analyze select  name_qualified from place,
to_tsquery('moscow')as query where fts_index @@ query;") at postgres.c:1017
 
#16 0x081d8798 in PostgresMain (argc=4, argv=0x8364c44,    username=0x8364c1c "megera") at postgres.c:3157
#17 0x081acc82 in BackendRun (port=0x837d1a8) at postmaster.c:2864
#18 0x081ac670 in BackendStartup (port=0x837d1a8) at postmaster.c:2505
#19 0x081aa910 in ServerLoop () at postmaster.c:1232
#20 0x081a9c59 in PostmasterMain (argc=1, argv=0x83633d0) at postmaster.c:941
#21 0x0816710e in main (argc=1, argv=0x83633d0) at main.c:268
#22 0x400edd06 in __libc_start_main () from /lib/libc.so.6


    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
---559023410-560155114-1125148906=:16397--


Re: bitmap scan cause core dump 8.1dev

От
Michael Fuhr
Дата:
On Sat, Aug 27, 2005 at 05:21:46PM +0400, Oleg Bartunov wrote:
> This query works as expected:
> # select  name_qualified from place
> where fts_index @@ to_tsquery('moscow');
> 
> This query (essentially the same as above) crashes:
> # select  name_qualified from place, to_tsquery('moscow') as query 
> where fts_index @@ query;
> 
> When I disable bitmap scanning (set enable_bitmapscan=off)
> second query works fine.

Disabling enable_bitmapscan causes my example to succeed, but when
I do get the error I don't get a crash, and the same query without
EXPLAIN succeeds:

CREATE TABLE foo (x integer);
CREATE INDEX foo_x_idx ON foo (x);
CREATE VIEW fooview AS SELECT count(*) FROM foo WHERE x < 10;

SET enable_bitmapscan TO on;

SELECT * FROM fooview;count 
-------    0
(1 row)

EXPLAIN SELECT * FROM fooview;
ERROR:  bogus varno: 5

SET enable_bitmapscan TO off;

EXPLAIN SELECT * FROM fooview;                                 QUERY PLAN                                  
------------------------------------------------------------------------------Aggregate  (cost=32.41..32.41 rows=1
width=0) ->  Index Scan using foo_x_idx on foo  (cost=0.00..30.63 rows=713 width=0)        Index Cond: (x < 10)
 
(3 rows)

-- 
Michael Fuhr


Re: bitmap scan cause core dump 8.1dev

От
Tom Lane
Дата:
Oleg Bartunov <oleg@sai.msu.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.
        regards, tom lane


Re: bitmap scan cause core dump 8.1dev

От
Michael Fuhr
Дата:
On Sat, Aug 27, 2005 at 10:28:30AM -0400, Tom Lane wrote:
> Oleg Bartunov <oleg@sai.msu.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


Re: bitmap scan cause core dump 8.1dev

От
Tom Lane
Дата:
Michael Fuhr <mike@fuhr.org> writes:
> On Sat, Aug 27, 2005 at 10:28:30AM -0400, Tom Lane wrote:
>> 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.

I had assumed this was the same bug as your "bogus varno" failure,
but actually it was a separate bug in plan reference fixup.  Not sure
yet that Oleg's original complaint is fixed, but we'll see.
        regards, tom lane


Re: bitmap scan cause core dump 8.1dev

От
Oleg Bartunov
Дата:
On Sat, 27 Aug 2005, Tom Lane wrote:

> Michael Fuhr <mike@fuhr.org> writes:
>> On Sat, Aug 27, 2005 at 10:28:30AM -0400, Tom Lane wrote:
>>> 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.
>
> I had assumed this was the same bug as your "bogus varno" failure,
> but actually it was a separate bug in plan reference fixup.  Not sure
> yet that Oleg's original complaint is fixed, but we'll see.

seems, my problem fixed now. Thanks Michael and Tom.

>
>             regards, tom lane
>
> ---------------------------(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
>
    Regards,        Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83