Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(JP) 全件scanの多重実行を複数回行うと、Assertion Failedとなることがある。 #16

Closed
taiki-k opened this issue May 15, 2014 · 1 comment
Labels
bug developer confirmed the steps to reproduce the problem, and does not work as expected

Comments

@taiki-k
Copy link
Contributor

taiki-k commented May 15, 2014

#15 と似た試験になりますが、pgbenchによる多重実行をシェルスクリプトでループさせて走らせていたところ、発生しました。

pgbenchで、2多重での実行で、高確率で発生します。(まれに、発生しないこともあります)

  • バックトレース
#0  0x0000003cdbc32925 in raise () from /lib64/libc.so.6
#1  0x0000003cdbc34105 in abort () from /lib64/libc.so.6
#2  0x0000000000949085 in ExceptionalCondition (conditionName=0x7f34909a754e "!(nremain > 0 && nmoved > 0)",
    errorType=0x7f34909a6f44 "FailedAssertion", fileName=0x7f34909a6fa9 "tcache.c", lineNumber=1579) at assert.c:54
#3  0x00007f349098afbd in tcache_split_tcnode (tc_head=0x7f3488702018, tc_node_old=0x7f3488702200) at tcache.c:1579
#4  0x00007f349098d96d in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f3488702200, tuple=0x16c1e08) at tcache.c:2118
#5  0x00007f349098d7f5 in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f34887065c8, tuple=0x16c1e08) at tcache.c:2086
#6  0x00007f349098d7f5 in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f3488706528, tuple=0x16c1e08) at tcache.c:2086
#7  0x00007f349098d7f5 in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f34887062a8, tuple=0x16c1e08) at tcache.c:2086
#8  0x00007f349098d7f5 in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f3488706028, tuple=0x16c1e08) at tcache.c:2086
#9  0x00007f349098d7f5 in tcache_insert_tuple (tc_head=0x7f3488702018, tc_node=0x7f34887035b0, tuple=0x16c1e08) at tcache.c:2086
#10 0x00007f349098da77 in tcache_build_main (tc_scan=0x16bf870) at tcache.c:2149
#11 0x00007f349098df41 in tcache_scan_next (tc_scan=0x16bf870) at tcache.c:2281
#12 0x00007f3490995bd0 in pgstrom_load_gpuscan (gss=0x16be658) at gpuscan.c:953
#13 0x00007f3490996ce4 in gpuscan_fetch_tuple (node=0x16be658) at gpuscan.c:1278
#14 0x00007f3490997163 in gpuscan_exec (node=0x16be658) at gpuscan.c:1373
#15 0x00000000006807e7 in ExecCustomPlan (cpstate=0x16be658) at nodeCustom.c:37
#16 0x00000000006684b5 in ExecProcNode (node=0x16be658) at execProcnode.c:453
#17 0x000000000067dab4 in agg_retrieve_direct (aggstate=0x16bdec0) at nodeAgg.c:1164
#18 0x000000000067d9cb in ExecAgg (node=0x16bdec0) at nodeAgg.c:1117
#19 0x0000000000668548 in ExecProcNode (node=0x16bdec0) at execProcnode.c:487
#20 0x0000000000665efe in ExecutePlan (estate=0x16bdda8, planstate=0x16bdec0, operation=CMD_SELECT, sendTuples=1 '\001',
    numberTuples=0, direction=ForwardScanDirection, dest=0x16b5448) at execMain.c:1475
#21 0x0000000000663da8 in standard_ExecutorRun (queryDesc=0x16a47f8, direction=ForwardScanDirection, count=0) at execMain.c:308
#22 0x0000000000663beb in ExecutorRun (queryDesc=0x16a47f8, direction=ForwardScanDirection, count=0) at execMain.c:256
#23 0x00000000007f964e in PortalRunSelect (portal=0x16bbd98, forward=1 '\001', count=0, dest=0x16b5448) at pquery.c:946
#24 0x00000000007f9275 in PortalRun (portal=0x16bbd98, count=9223372036854775807, isTopLevel=1 '\001', dest=0x16b5448,
    altdest=0x16b5448, completionTag=0x7fff14bd5a40 "") at pquery.c:790
#25 0x00000000007f29e2 in exec_simple_query (query_string=0x166d568 "SELECT count(*) FROM million_table_i8f8 WHERE data < 0.01;")
    at postgres.c:1045
#26 0x00000000007f7162 in PostgresMain (argc=1, argv=0x15ff520, dbname=0x15ff418 "pgstrom_test", username=0x15ff3f8 "tkondo")
    at postgres.c:4004
#27 0x000000000076e18a in BackendRun (port=0x1627230) at postmaster.c:4104
#28 0x000000000076d840 in BackendStartup (port=0x1627230) at postmaster.c:3778
#29 0x0000000000769bfe in ServerLoop () at postmaster.c:1569
#30 0x0000000000769251 in PostmasterMain (argc=1, argv=0x15fe3b0) at postmaster.c:1222
#31 0x00000000006b8aee in main (argc=1, argv=0x15fe3b0) at main.c:223
  • 実行したクエリー
SELECT count(*) FROM million_table_i8f8 WHERE data < 0.01;
  • 対象のテーブル
   Table "public.million_table_i8f8"
 Column |       Type       | Modifiers
--------+------------------+-----------
 id     | bigint           |
 data   | double precision |

※ million_table ( #10 で使用したもの)をCOPYでファイルに出力し、million_table_i8f8に入力したものです。

  • 使用したシェルスクリプト
#!/bin/bash

RES=0;
COUNT=1;

while [ $RES -eq 0 ];
do
        echo -n Try count $COUNT Start at ;
        date;
        pgbench $@;
        RES=$?;
        COUNT=`expr $COUNT + 1`;
done;

この時のCoreは、以下にbzip2圧縮して置いてありますので、解析にご利用ください。

/home/tkondo/coding/postgres/pg_strom_test/core/core.502.2014-05-15_18-12.bz2
@kaigai
Copy link
Contributor

kaigai commented May 20, 2014

tcache_headを登録するハッシュ表のロックに関連する問題を修正後、再現しないので、
一旦クローズとする。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug developer confirmed the steps to reproduce the problem, and does not work as expected
Projects
None yet
Development

No branches or pull requests

2 participants