tripping an assert in 8.1.6
От | Brian Hurt |
---|---|
Тема | tripping an assert in 8.1.6 |
Дата | |
Msg-id | 45B62571.7020705@janestcapital.com обсуждение исходный текст |
Ответы |
Re: tripping an assert in 8.1.6 (more info)
|
Список | pgsql-hackers |
Hello all. It seems I'm tripping an assert in 8.1.6- the assert on line 219 of src/backend/executor/execScan.c (found by running gdb on a core dump). This is on x86 and Redhat Linux (forget which version). Note that if I recompile 8.1.6 with asserts turned off the query completes just fine. I'm trying to put together an example which reproduces the problem without requiring half our company's data- that should follow soon. The gdb backtrace is: > #0 0xffffe410 in __kernel_vsyscall () > (gdb) bt > #0 0xffffe410 in __kernel_vsyscall () > #1 0xb7d2dee9 in raise () from /lib/libc.so.6 > #2 0xb7d2f4f1 in abort () from /lib/libc.so.6 > #3 0x0824f931 in ExceptionalCondition (conditionName=Variable > "conditionName" is not available. > ) at assert.c:51 > #4 0x081537ac in ExecAssignScanProjectionInfo (node=0x8426bec) > at execScan.c:219 > #5 0x08161339 in ExecInitSubqueryScan (node=0x8412de4, estate=0x8426ad4) > at nodeSubqueryscan.c:212 > #6 0x0814e0e4 in ExecInitNode (node=0x8412de4, estate=0x8426ad4) > at execProcnode.c:179 > #7 0x0814c554 in ExecutorStart (queryDesc=0x842554c, explainOnly=1 > '\001') > at execMain.c:618 > #8 0x081193f5 in ExplainOnePlan (queryDesc=0x842554c, stmt=0x839afe4, > tstate=0x83cbdac) at explain.c:243 > #9 0x081198ac in ExplainOneQuery (query=0x83b88e4, stmt=0x839afe4, > tstate=0x83cbdac) at explain.c:214 > #10 0x08119a92 in ExplainQuery (stmt=0x839afe4, dest=0x83b8a54) > at explain.c:121 > #11 0x081da391 in PortalRunUtility (portal=0x83b67b4, query=0x839b07c, > dest=0x83b8a54, completionTag=0x0) at pquery.c:987 > #12 0x081db6dc in PortalRun (portal=0x83b67b4, count=2147483647, > dest=0x839b030, altdest=0x839b030, completionTag=0xbf9efee8 "") > at pquery.c:637 > #13 0x081d713c in exec_simple_query ( > query_string=0x839a26c "explain SELECT action, bloomberg_code, > composite_bloomberg_code, reuters_code, cusip_code, sedol_code, > isin_code FROM vw_ca_generic_actions WHERE (action_date >= > '20070122'::date) AND (action_date <= "...) > at postgres.c:1004 > #14 0x081d8bd3 in PostgresMain (argc=4, argv=0x83593f0, > username=0x83593b8 "postgres") at postgres.c:3232 > #15 0x081aca37 in ServerLoop () at postmaster.c:2865 > #16 0x081ad936 in PostmasterMain (argc=3, argv=0x8358560) at > postmaster.c:941 > #17 0x0816c1c9 in main (argc=3, argv=Cannot access memory at address > 0x1515 > ) at main.c:265 > This is mainly a "heads up- bug incomming" message. Thanks. Brian
В списке pgsql-hackers по дате отправления: