This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without 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) at nodeIndexscan.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--

Search Discussions

  • Michael Fuhr at Aug 27, 2005 at 2:17 pm

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

    (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
  • Tom Lane at Aug 27, 2005 at 2:28 pm

    Oleg Bartunov 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
  • Michael Fuhr at Aug 27, 2005 at 3:12 pm

    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
  • Tom Lane at Aug 27, 2005 at 6:07 pm

    Michael Fuhr 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
  • Oleg Bartunov at Aug 27, 2005 at 6:32 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 27, '05 at 1:21p
activeAug 27, '05 at 6:32p
posts6
users3
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase