Bugs item #2728891, was opened at 2009-04-03 23:12
Message generated for change (Comment added) made by stmane
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2728891&group_id=56967

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SQL/Core
Group: SQL CVS Head
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Stefan de Konink (skinkie)
Assigned to: Niels Nes (nielsnes)
>Summary: SQL: where IN (....) crashes mserver5

Initial Comment:
A very long IN part crashes the mserver5 code; gdb return the 'mcount' issue.

I rewrote the query in 'OR' and that resulted in a 'nice' error message.

QUERY = delete from nodes_legacy where id = 1278
ERROR = !memory exhausted in: "delete from nodes_legacy where id = 1278
        ! or id = 1279
        ! or id = 1280
        ! or id = 1281
...

Never the less, the individual deletes are very slow. I would like to know how 
I could optimise this problem.

----------------------------------------------------------------------

>Comment By: Stefan Manegold (stmane)
Date: 2009-08-14 13:52

Message:
tagged subject


----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-08-11 12:10

Message:
The original backtrace doesn't look like this at all. So maybe when this is
finished it will unveil another bug :-\

----------------------------------------------------------------------

Comment By: Stefan Manegold (stmane)
Date: 2009-08-11 11:45

Message:
Yet another stack overflow due to too deep recursion.


----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-08-11 02:45

Message:
create table test (number integer);
insert into test values (1);

(execute attached query)

backtrace:
#0  0x00007f84c5e35d07 in free () from /lib/libc.so.6
#1  0x00007f84c8020fbb in GDKfree_ (blk=0x666cb58) at
../../../src/gdk/gdk_utils.mx:1156
#2  0x00007f84c8021044 in GDKfree (blk=0x666cb58) at
../../../src/gdk/gdk_utils.mx:1165
#3  0x00007f84b6e667c9 in exp_destroy (exp=0x666caf8) at
../../../src/server/rel_exp.mx:132
#4  0x00007f84b6ea1adb in node_destroy (l=0x666cab8, n=0x666cb98) at
../../../src/common/sql_list.mx:52
#5  0x00007f84b6ea1b2f in list_destroy (l=0x666cab8) at
../../../src/common/sql_list.mx:66
#6  0x00007f84b6e5192c in rel_destroy_ (rel=0x666ca68) at
../../../src/server/rel_select.mx:107
#7  0x00007f84b6e51b50 in rel_destroy (rel=0x666ca68) at
../../../src/server/rel_select.mx:143
#8  0x00007f84b6e519cd in rel_destroy_ (rel=0x666cd68) at
../../../src/server/rel_select.mx:114
#9  0x00007f84b6e51b50 in rel_destroy (rel=0x666cd68) at
../../../src/server/rel_select.mx:143
#10 0x00007f84b6e519cd in rel_destroy_ (rel=0x666d068) at
../../../src/server/rel_select.mx:114
#11 0x00007f84b6e51b50 in rel_destroy (rel=0x666d068) at
../../../src/server/rel_select.mx:143

...and on and on.

----------------------------------------------------------------------

Comment By: Martin Kersten (mlkersten)
Date: 2009-08-06 16:38

Message:
Awaiting for the original query.

----------------------------------------------------------------------

Comment By: Niels Nes (nielsnes)
Date: 2009-05-28 22:53

Message:
do you still have the original query, ie the one with the big 'in' part. 

----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-04-05 18:13

Message:
My actual problem is solved using:

START TRANSACTION;
CREATE TEMPORARY TABLE delete_nodes (id integer);
COPY 228089 RECORDS INTO delete_nodes from '/tmp/deletemeuk.sql' USING
DELIMITERS ',', '\n', '''';
delete from nodes_legacy where id in (select id from delete_nodes); 
DROP TABLE delete_nodes;
COMMIT;

Which finishes in a minute.

----------------------------------------------------------------------

Comment By: Stefan de Konink (skinkie)
Date: 2009-04-05 17:59

Message:
[Switching to thread 1 (Thread 0x7ffff6a377b0 (LWP 26534))]#0 
0x0000003c1a40df5b in read () from /lib64/libpthread.so.0
(gdb) where
#0  0x0000003c1a40df5b in read () from /lib64/libpthread.so.0
#1  0x0000003c22027581 in rl_getc () from /lib64/libreadline.so.5
#2  0x0000003c22014ce1 in readline_internal_char () from
/lib64/libreadline.so.5
#3  0x0000003c220151c5 in readline () from /lib64/libreadline.so.5
#4  0x00007ffff7d3c795 in getConsoleInput (prompt=0x613a78 ">",
linemode=0, exit_on_error=1) at ../../../src/mal/mal_readline.mx:342
#5  0x00007ffff7d3ce4f in readConsole (cntxt=0x604820) at
../../../src/mal/mal_readline.mx:499
#6  0x00007ffff7cefaf6 in MALreader (c=0x604820) at
../../../src/mal/mal_session.mx:532
#7  0x00007ffff7d32d79 in runPhase (c=0x604820, phase=0) at
../../../src/mal/mal_scenario.mx:591
#8  0x00007ffff7d32e1a in runScenarioBody (c=0x604820) at
../../../src/mal/mal_scenario.mx:619
#9  0x00007ffff7d330a9 in runScenario (c=0x604820) at
../../../src/mal/mal_scenario.mx:661
#10 0x00007ffff7cef8bd in MSserveClient (dummy=0x604820) at
../../../src/mal/mal_session.mx:460
#11 0x0000000000402f74 in main (argc=5, av=0x7fffffffe0f8) at
../../../src/tools/mserver5.mx:619
[17:56:38] … [Switching to thread 2 (Thread 0x7fffec551950 (LWP
26543))]#0  0x0000003c1a40e851 in nanosleep () from /lib64/libpthread.so.0
(gdb) where
#0  0x0000003c1a40e851 in nanosleep () from /lib64/libpthread.so.0
#1  0x00007ffff7774b41 in MT_sleep_ms (ms=5000) at
../../../src/gdk/gdk_posix.mx:2090
#2  0x00007ffff74ca017 in GDKvmtrim (limit=0x7ffff7aa39b0) at
../../../src/gdk/gdk_utils.mx:1471
#3  0x00007ffff7773e36 in wrapper_routine (data=0x7fffffffdb40) at
../../../src/gdk/gdk_posix.mx:955
#4  0x0000003c1a4073da in start_thread () from /lib64/libpthread.so.0
#5  0x0000003c19ce62bd in clone () from /lib64/libc.so.6
[17:56:47] … (gdb) where
#0  0x0000003c19cdeaa2 in select () from /lib64/libc.so.6
#1  0x00007fffe593e015 in SERVERlistenThread (Sock=0xd84588) at
../../../../src/modules/mal/mal_mapi.mx:525
#2  0x00007ffff7773e36 in wrapper_routine (data=0x7fffffffc4f0) at
../../../src/gdk/gdk_posix.mx:955
#3  0x0000003c1a4073da in start_thread () from /lib64/libpthread.so.0
#4  0x0000003c19ce62bd in clone () from /lib64/libc.so.6
[17:56:55] … (gdb) where
#0  0x0000003c1a40e851 in nanosleep () from /lib64/libpthread.so.0
#1  0x00007ffff7774b41 in MT_sleep_ms (ms=30000) at
../../../src/gdk/gdk_posix.mx:2090
#2  0x00007fffe27b9f81 in store_manager () at
../../../src/storage/store.mx:1431
#3  0x00007fffe277dd1e in mvc_logmanager () at
../../../src/server/sql_mvc.mx:342
#4  0x00007ffff7773e36 in wrapper_routine (data=0x7fffe325bb10) at
../../../src/gdk/gdk_posix.mx:955
#5  0x0000003c1a4073da in start_thread () from /lib64/libpthread.so.0
#6  0x0000003c19ce62bd in clone () from /lib64/libc.so.6
[17:57:55] … [Switching to thread 5 (Thread 0x7fffe1cd8950 (LWP
26558))]#0  0x0000003c19cea244 in mcount () from /lib64/libc.so.6
(gdb) where
#0  0x0000003c19cea244 in mcount () from /lib64/libc.so.6
#1  0x0000000000000000 in ?? ()

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=2728891&group_id=56967

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs

Reply via email to