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)  (Brian Hurt <bhurt@janestcapital.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Piggybacking vacuum I/O
Следующее
От:
Дата:
Сообщение: Re: STOP all user access except for admin for a few minutes?