Thread: bitmap scan cause core dump 8.1dev
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--
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
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
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
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
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