April 2010 - users-list

[MonetDB-users] how to grant privileges to creating tables? (more specific version)
by Min Lu 25 Apr '10

25 Apr '10

Dear all, I just want to address my question in last message in a more specific way. Actually I am wondering if I can grant privileges to creating local/global temporary tables to a normal user other than monetdb. And what is the complete list of priveleges known to MonetDB? Thanks, Min

2 2

[MonetDB-users] Fedora 12 cannot install public key
by dariuszs 23 Apr '10

23 Apr '10

Hi, Just trying to install public key on another server [root@monetdb ~]# rpm --import http://monetdb.cwi.nl/downloads/MonetDB-GPG-KEY error: http://monetdb.cwi.nl/downloads/MonetDB-GPG-KEY: import failed. [root@monetdb ~]#

1 1

[MonetDB-users] mal index
by Miguel Ángel Águila Lorente 23 Apr '10

23 Apr '10

Hello, I'm working in a research problem and we need to create a graph database. We think that MonetDB can be useful to represent this graph since the use of bats may make the graph traversal efficient. Nevertheless, SQL is limited for the type of operations that we need to do, and that is why we have decided to resort to MAL. Our database is like this: - Nodes: a) node ident b) name - Edges: a) edge ident b) head node ident c) tail node ident One of the operations is to find the node with maximum out degree and, after that, to do a BFS using this node as the source. I have stored all the information in bats: batNode1=[oid,node ident] batNode2=[oid,name] batEdge=[oid, edge ident] batEdgeHead=[oid, head node ident] batEdgeTail=[oid,tail node ident] For getting the node with the maximum out degree, I access batEdgeHead and store the number of occurrences of every node id in a batAux. batAux=[node ident, times] After that I only select the node id with the largest number of occurrences. Now, we are ready to do the BFS. In every iteration, I have to save all the tail nodes for exploring them in the next generation. This is the pseudocode explanation: Put the node id to NodesToVisit While there are NodesToVisit currentNode=NodesToVisit; edgeToVisit=get edges idents from batEdgeHead from currentNode ident While there are edgesToVisit currentEdge=edgesToVisit nodeFinal=get tail node ident from batEdgeTail from currentEdge ident If notExist nodeFinal in NodesToVisit put nodeFinal in NodesToVisit endIf endWhile endWhile The main problem happens when I perform a select from batEdgeHead from the ident node. batEdgeHead might become very large and accessing it might be very expensive in terms of time. Is there any kind of indexing? I tried with crackers and AVL index but, if I am not wrong, this is only useful if I had to do the same selection more than once. The number of the nodes is 325.000 and the number of edges 925.000. At the end of this e-mail you will find the code. May any one help in improving the performance of this code? Best regards, Miquel Àngel Àguila Bat equivalence: batEdge, batNode1 --> b1:= bat.new(:oid,:lng); batNode2 --> b2:= bat.new(:oid,:str); batEdgeHead --> rh:= bat.new(:oid,:lng); batEdgeTail --> rt:= bat.new(:oid,:lng); batType --> b4:= bat.new(:oid, int) (Type: 1. nodeType1, 2. nodeType2 , 3. edgeType1, 4. edgeType2, 5. edgeType3) Loaded the bats, here is the code: Maxium out degree:----------------------------------------------------- edart:=algebra.select(b4,3); nodOut:=algebra.semijoin(rh,edart); res:=bat.new(:lng,:int); valor:=0; barrier (mloop16:lng ,h16:oid ,tl16:lng ) := bat.newIterator(nodOut); bite1:=algebra.exist(res,tl16); barrier ifpart:= bite1; valor:=algebra.find(res, tl16); valor:=calc.+(valor,1); res:=bat.replace(res,tl16,valor); exit ifpart; barrier elsepart:= calc.!=(bite1,true); bat.insert(res,tl16,1); exit elsepart; redo (mloop16:lng ,h16:oid ,tl16:lng ) := bat.hasMoreElements(nodOut); exit mloop16:lng ; maxOutDegree:=aggr.max(res); node:=algebra.select(res,maxOutDegree); io.print(node); nodart:=algebra.select(b4,1); nodart2:=algebra.semijoin(b1,nodart); ident2:=algebra.join(nodart2,node); name2:=algebra.semijoin(b3,ident2); secondtime:=alarm.time(); #Traversals------------------------------------------------------------ node2:=algebra.semijoin(b1,name2); aux:=0:lng; idoid:=0@0; barrier (mloop17:lng ,h17:oid ,tl17:lng) := bat.newIterator(node2); aux:=tl17; idoid:=h17; exit mloop17:lng ; nod:=bat.new(:lng,:lng); dif:=bat.new(:lng,:lng); vis:=bat.new(:lng,:lng); ar:=bat.new(:oid,:oid); tr:=bat.new(:oid,:oid); bat.insert(nod,aux,aux); dif:=algebra.difference(nod,vis); outer6:= aggr.count(dif); rhtaux:=bat.new(:oid,:int); rhaux:=bat.new(:oid,:lng); rtaux:=bat.new(:oid,:lng); rhtaux:=algebra.select(b4,3); rtaux:=algebra.semijoin(rt,rhtaux); rhaux:=algebra.semijoin(rh,rhtaux); barrier outer:=true; barrier (mloop18:lng ,h18:lng ,tl18:lng ) := bat.newIterator(dif); # This is the problem, I need to do a lot of selects rhaux2:=algebra.select(rhaux,tl18); rtaux2:=algebra.semijoin(rtaux,rhaux2); barrier (mloop19:lng ,h19:oid,tl19:lng ) := bat.newIterator(rtaux2); bite1:=algebra.exist(nod,tl19); barrier ifpart:= bite1; bat.insert(tr,h19,h19); exit ifpart; barrier elsepart:= calc.!=(bite1,true); bat.insert(ar,h19,h19); bat.insert(nod,tl19,tl19); exit elsepart; redo (mloop19:lng ,h19:oid ,tl19:lng ) := bat.hasMoreElements(rtaux2); exit mloop19:lng ; bat.insert(vis,h18,tl18); redo (mloop18:lng ,h18:lng ,tl18:lng ) := bat.hasMoreElements(dif); exit mloop18:lng ; dif:=algebra.difference(nod,vis); outer6:= aggr.count(dif); outer:=calc.!=(outer6,0); redo outer:=calc.!=(outer6,0); exit outer;

4 4

Re: [MonetDB-users] Core Dump upon COPY on SPARC
by Hering Cheng 23 Apr '10

23 Apr '10

Using Feb2010 release resulted in a different error. This time, mserver5 did not crash: MAPI = chenher@rdcuxsrv220:50000 QUERY = COPY 34274958 RECORDS INTO app.t_compute_all_closeprice FROM '/home/chenher/gaal/tmp/tar/t_compute_all_closeprice.txt' DELIMITERS '|', '\n'; ERROR = !MALException:!ERROR: HEAPextend: failed to extend to 274199664 for 17/1745tail Here is the configuration from log file: 2010-04-21 13:11:51 MSG tar[537]: # MonetDB server v5.18.1, based on kernel v1.36.1 2010-04-21 13:11:51 MSG tar[537]: # Serving database 'tar', using 16 threads 2010-04-21 13:11:51 MSG tar[537]: # Compiled for sparc-sun-solaris2.10/64bit with 64bit OIDs dynamically linked 2010-04-21 13:11:51 MSG tar[537]: # Found 32.000 GiB available main-memory. 2010-04-21 13:11:51 MSG tar[537]: # Copyright (c) 1993-July 2008 CWI. 2010-04-21 13:11:51 MSG tar[537]: # Copyright (c) August 2008-2010 MonetDB B.V., all rights reserved 2010-04-21 13:11:51 MSG tar[537]: # Visit http://monetdb.cwi.nl/ for further information 2010-04-21 13:11:51 MSG tar[537]: # Listening for connection requests on mapi:monetdb://127.0.0.1:50001/ 2010-04-21 13:11:52 MSG tar[537]: # MonetDB/SQL module v2.36.1 loaded Any suggestion? On Wed, Apr 21, 2010 at 1:16 PM, Hering Cheng <hering.cheng(a)computer.org>wrote: > The statement I gave is the only statement that I passed to mclient, using > --statement argument. > > > On Wed, Apr 21, 2010 at 11:32 AM, Niels Nes <Niels.Nes(a)cwi.nl> wrote: > >> On Wed, Apr 21, 2010 at 11:08:46AM -0700, Hering Cheng wrote: >> > Here is the single COPY statement I was using: >> > >> > COPY 34274958 RECORDS INTO app.t_compute_all_closeprice FROM '/home/ >> > chenher/gaal/tmp/tar/t_compute_all_closeprice.txt' DELIMITERS '|', '\ >> > n'; >> >> I was wondering because the crash you have seems to indicate its >> in the commit, ie your load finished but then the commit (auto or not) >> crashes. Probably because of some out of memory problem. >> >> niels >> > >> > On Wed, Apr 21, 2010 at 11:02 AM, Niels Nes <Niels.Nes(a)cwi.nl> wrote: >> > >> > On Wed, Apr 21, 2010 at 10:48:48AM -0700, Hering Cheng wrote: >> > > Hi, >> > > >> > > I am trying to load 77 GB of data (or 34,274,958 records) into >> > MonetDB, >> > > using the Feb2010 SP1 source code compiled on Solaris SPARC with >> > Sun >> > > Studio 12.1 compiler with debugging enabled, and the database >> > crashes 5 >> > > hours into the loading. Here is some information about my >> > > configuration: >> > > >> > > I start up with Merovingian like this: >> > > >> > > $ ( ulimit -d $[32*1024*1024]; export LD_PRELOAD_64=/usr/lib/64/ >> > > libumem.so:${LD_PRELOAD_64}; export LD_PRELOAD=/usr/lib/ >> > libumem.so:$ >> > > {LD_PRELOAD}; export MONETDB5CONF=/GAAL/chenher/ >> > rdcuxsrv220-local-disk/ >> > > chenher/monetdb/feb2010sp1/etc/monetdb5.conf; /GAAL/chenher/share >> > / >> > > monetdb/distro-sparc-feb2010-sp1-64bit/bin/merovingian; ) >> > > >> > > Here are the relevent log sections: >> > > >> > > 2010-04-16 13:25:28 MSG merovingian[4302]: starting database >> > 'tar', up >> > > min/avg/max: 4m/4m/4m, crash average: 0.00 0.00 0.00 (1-1=0) >> > > 2010-04-16 13:25:29 MSG tar[15594]: arguments: /GAAL/chenher/ >> > share/ >> > > monetdb/distro-sparc-feb2010-sp1-64bit/bin/mserver5 --config=/ >> > GAAL/ >> > > chenher/rdcuxsrv220-local-disk/chenher/monetdb/feb2010sp1/etc/ >> > > monetdb5.conf --dbname=tar --dbinit=include sql; --set >> > merovingian_uri= >> > > mapi:monetdb://rdcuxsrv220:50000/tar --set monet_daemon=yes --set >> > > mapi_open=false --set mapi_autosense=true --set mapi_port=50001 >> > --set >> > > monet_vault_key=/GAAL/chenher/rdcuxsrv220-local-disk/chenher/ >> > monetdb/ >> > > feb2010sp1/var/MonetDB5/dbfarm/tar/.vaultkey --set sql_optimizer= >> > > default_pipe >> > > 2010-04-16 13:25:34 MSG tar[15594]: # MonetDB server v5.18.3, >> > based on >> > > kernel v1.36.3 >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Serving database 'tar', >> > using 16 >> > > threads >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Compiled for >> > > sparc-sun-solaris2.10/64bit with 64bit OIDs dynamically linked >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Found 32.000 GiB available >> > > main-memory. >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Copyright (c) 1993-July >> > 2008 CWI. >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Copyright (c) August >> > 2008-2010 >> > > MonetDB B.V., all rights reserved >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Visit http://monetdb.cwi.nl >> > / for >> > > further information >> > > 2010-04-16 13:25:34 MSG tar[15594]: # Listening for connection >> > requests >> > > on mapi:monetdb://127.0.0.1:50001/ >> > > 2010-04-16 13:25:35 MSG tar[15594]: # MonetDB/SQL module v2.36.3 >> > loaded >> > > 2010-04-16 13:25:35 MSG control[4302]: rdcuxsrv220:58146: started >> > > database 'tar' >> > > ... >> > > 2010-04-21 10:23:37 MSG merovingian[4302]: database 'tar' (15594) >> > has >> > > crashed (dumped core) >> > > >> > > Using Sun's DBX tool to examine the crash: >> > > >> > > ... >> > > t@212 (l@212) terminated by signal SEGV (no mapping at the fault >> > > address) >> > > Current function is temp_create >> > > 87 temp_dup(b->batCacheid); >> > > (dbx) where >> > > current thread: t@212 >> > > =>[1] temp_create(b = (nil)), line 87 in "bat_utils.c" >> > > [2] ebat2real(b = 5714, ibase = 0), line 162 in "bat_utils.c" >> > > [3] delta_append_bat(bat = 0x104923c98, i = 0x10143ec98), line >> > 234 in >> > > "bat_storage.c" >> > > [4] append_col(tr = 0x104fe1e98, c = 0x1045c7af8, i = >> > 0x10143ec98, >> > > tpe = 5), line 267 in "bat_storage.c" >> > > [5] mvc_append_wrap(cntxt = 0xffffffff7f352c00, mb = >> > 0x1050d5d98, stk >> > > = 0x101816018, pci = 0x1056a7c18), line 1120 in "sql.c" >> > > [6] runMALsequence(cntxt = 0xffffffff7f352c00, mb = >> > 0x1050d5d98, >> > > startpc = 1, stoppc = 0, stk = 0x101816018, env = (nil), >> > pcicaller = >> > > (nil)), line 2908 in "mal_interpreter.c" >> > > [7] callMAL(cntxt = 0xffffffff7f352c00, mb = 0x1050d5d98, env = >> > > 0xfffffffddabff908, argv = 0xfffffffddabff968, debug = '\0'), >> > line 402 >> > > in "mal_interpreter.c" >> > > [8] SQLexecutePrepared(c = 0xffffffff7f352c00, be = >> > 0x1050f0ec8, q = >> > > 0x104fe1b18), line 1196 in "sql_scenario.c" >> > > [9] SQLengineIntern(c = 0xffffffff7f352c00, be = 0x1050f0ec8), >> > line >> > > 1249 in "sql_scenario.c" >> > > [10] SQLengine(c = 0xffffffff7f352c00), line 1349 in >> > "sql_scenario.c" >> > > [11] runPhase(c = 0xffffffff7f352c00, phase = 4), line 363 in >> > > "mal_scenario.c" >> > > [12] runScenarioBody(c = 0xffffffff7f352c00), line 412 in >> > > "mal_scenario.c" >> > > [13] runScenario(c = 0xffffffff7f352c00), line 438 in >> > > "mal_scenario.c" >> > > [14] MSserveClient(dummy = 0xffffffff7f352c00), line 368 in >> > > "mal_session.c" >> > > (dbx) threads >> > > t@1 a l@1 ?() LWP suspended in __pollsys() >> > > t@2 a l@2 SERVERlistenThread() LWP suspended in >> > __pollsys >> > > () >> > > t@3 a l@3 mvc_logmanager() LWP suspended in >> > __pollsys() >> > > t@4 b l@4 umem_update_thread() sleep on (unknown) in >> > > __lwp_park() >> > > t@13 a l@13 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@14 a l@14 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@15 a l@15 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@16 a l@16 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@17 a l@17 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@18 a l@18 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@19 a l@19 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@20 a l@20 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@21 a l@21 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@22 a l@22 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@23 a l@23 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@24 a l@24 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@25 a l@25 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@26 a l@26 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@27 a l@27 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > t@28 a l@28 runDFLOWworker() sleep on 0x101ea9a48 in >> > > __lwp_park() >> > > o> t@212 a l@212 ?() signal SIGSEGV in temp_create() >> > > >> > > With Feb2010 release, I managed to load a much larger database >> > without >> > > a crash. I will try loading this smaller data set again with the >> > > Feb2010 release and report what happens. In the meantime, can >> > you give >> > > me some suggestions? >> > > >> > > Thanks. >> > > Hering >> > > >> > >> > Are you loading with a single COPY into or with several insert >> > into? >> > >> > Niels >> > >> > > >> > >> ------------------------------------------------------------------------------ >> > >> > > _______________________________________________ >> > > MonetDB-users mailing list >> > > MonetDB-users(a)lists.sourceforge.net >> > > https://lists.sourceforge.net/lists/listinfo/monetdb-users >> > >> > >> > -- >> > Niels Nes, Centrum Wiskunde & Informatica (CWI) >> > Science Park 123, 1098 XG Amsterdam, The Netherlands >> > room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl<sip%3A4098(a)sip.cwi.nl> >> > url: http://www.cwi.nl/~niels <http://www.cwi.nl/%7Eniels> >> e-mail: Niels.Nes(a)cwi.nl >> > >> > >> >> -- >> Niels Nes, Centrum Wiskunde & Informatica (CWI) >> Science Park 123, 1098 XG Amsterdam, The Netherlands >> room L3.14, phone ++31 20 592-4098 sip:4098@sip.cwi.nl<sip%3A4098(a)sip.cwi.nl> >> url: http://www.cwi.nl/~niels <http://www.cwi.nl/%7Eniels> e-mail: >> Niels.Nes(a)cwi.nl >> > >

2 3

[MonetDB-users] copy into file
by dariuszs 22 Apr '10

22 Apr '10

Hi, It looks like the same problem exists no matter what the OS (Fedora 12 or Ubuntu 9.10 or Windows) and this worked in Nov2009-SP1 release. When you try: sql>copy select * from table1 limit 1000 into '/tmp/output.txt'; MAPI = monetdb@localhost:50000 ACTION= read_line QUERY = copy select * from table1 limit 1000 into '/tmp/output.txt'; ERROR = !Connection terminated Timer 1105.876 msec You have mail in /var/spool/mail/root [root@monetdb ~]# [root@monetdb /]# mserver5 --version MonetDB server v5.18.3 (64-bit), based on kernel v1.36.3 (64-bit oids) Copyright (c) 1993-July 2008 CWI Copyright (c) August 2008-2010 MonetDB B.V., all rights reserved Visit http://monetdb.cwi.nl/ for further information Found 47.3GiB available memory, 16 available cpu cores Configured for prefix: /usr Libraries: libpcre: 7.8 2008-09-05 (compiled with 7.8) openssl: OpenSSL 1.0.0-beta4 10 Nov 2009 (compiled with OpenSSL 1.0.0-fips-beta4 10 Nov 2009) libxml2: 2.7.6 (compiled with 2.7.6) Compiled by: mockbuild@ (x86_64-redhat-linux-gnu) Compilation: gcc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -ftree-vectorize Linking : ld -IPA -m elf_x86_64 Please help. Thanks. Dariusz.

4 27

[MonetDB-users] SQL constraints and performance
by Isidor Zeuner 22 Apr '10

22 Apr '10

Dear MonetDB developers, from my own experiences regarding database engine design, I know that SQL constraints can be used to increase performance because the query planner can use them to reason about certain regularities in the data. On the other hand, they come with a cost as the engine is supposed to enforce them. Are there any common rules on how constraints and performance correlate in MonetDB, which could be used to adapt a schema to work especially fast with MonetDB? Best regards, Isidor

1 0

[MonetDB-users] Core Dump upon COPY on SPARC
by Hering Cheng 21 Apr '10

21 Apr '10

Hi, I am trying to load 77 GB of data (or 34,274,958 records) into MonetDB, using the Feb2010 SP1 source code compiled on Solaris SPARC with Sun Studio 12.1 compiler with debugging enabled, and the database crashes 5 hours into the loading. Here is some information about my configuration: I start up with Merovingian like this: $ ( ulimit -d $[32*1024*1024]; export LD_PRELOAD_64=/usr/lib/64/libumem.so:${LD_PRELOAD_64}; export LD_PRELOAD=/usr/lib/libumem.so:${LD_PRELOAD}; export MONETDB5CONF=/GAAL/chenher/rdcuxsrv220-local-disk/chenher/monetdb/feb2010sp1/etc/monetdb5.conf; /GAAL/chenher/share/monetdb/distro-sparc-feb2010-sp1-64bit/bin/merovingian; ) Here are the relevent log sections: 2010-04-16 13:25:28 MSG merovingian[4302]: starting database 'tar', up min/avg/max: 4m/4m/4m, crash average: 0.00 0.00 0.00 (1-1=0) 2010-04-16 13:25:29 MSG tar[15594]: arguments: /GAAL/chenher/share/monetdb/distro-sparc-feb2010-sp1-64bit/bin/mserver5 --config=/GAAL/chenher/rdcuxsrv220-local-disk/chenher/monetdb/feb2010sp1/etc/monetdb5.conf --dbname=tar --dbinit=include sql; --set merovingian_uri=mapi:monetdb://rdcuxsrv220:50000/tar --set monet_daemon=yes --set mapi_open=false --set mapi_autosense=true --set mapi_port=50001 --set monet_vault_key=/GAAL/chenher/rdcuxsrv220-local-disk/chenher/monetdb/feb2010sp1/var/MonetDB5/dbfarm/tar/.vaultkey --set sql_optimizer=default_pipe 2010-04-16 13:25:34 MSG tar[15594]: # MonetDB server v5.18.3, based on kernel v1.36.3 2010-04-16 13:25:34 MSG tar[15594]: # Serving database 'tar', using 16 threads 2010-04-16 13:25:34 MSG tar[15594]: # Compiled for sparc-sun-solaris2.10/64bit with 64bit OIDs dynamically linked 2010-04-16 13:25:34 MSG tar[15594]: # Found 32.000 GiB available main-memory. 2010-04-16 13:25:34 MSG tar[15594]: # Copyright (c) 1993-July 2008 CWI. 2010-04-16 13:25:34 MSG tar[15594]: # Copyright (c) August 2008-2010 MonetDB B.V., all rights reserved 2010-04-16 13:25:34 MSG tar[15594]: # Visit http://monetdb.cwi.nl/ for further information 2010-04-16 13:25:34 MSG tar[15594]: # Listening for connection requests on mapi:monetdb://127.0.0.1:50001/ 2010-04-16 13:25:35 MSG tar[15594]: # MonetDB/SQL module v2.36.3 loaded 2010-04-16 13:25:35 MSG control[4302]: rdcuxsrv220:58146: started database 'tar' ... 2010-04-21 10:23:37 MSG merovingian[4302]: database 'tar' (15594) has crashed (dumped core) Using Sun's DBX tool to examine the crash: ... t@212 (l@212) terminated by signal SEGV (no mapping at the fault address) Current function is temp_create 87 temp_dup(b->batCacheid); (dbx) where current thread: t@212 =>[1] temp_create(b = (nil)), line 87 in "bat_utils.c" [2] ebat2real(b = 5714, ibase = 0), line 162 in "bat_utils.c" [3] delta_append_bat(bat = 0x104923c98, i = 0x10143ec98), line 234 in "bat_storage.c" [4] append_col(tr = 0x104fe1e98, c = 0x1045c7af8, i = 0x10143ec98, tpe = 5), line 267 in "bat_storage.c" [5] mvc_append_wrap(cntxt = 0xffffffff7f352c00, mb = 0x1050d5d98, stk = 0x101816018, pci = 0x1056a7c18), line 1120 in "sql.c" [6] runMALsequence(cntxt = 0xffffffff7f352c00, mb = 0x1050d5d98, startpc = 1, stoppc = 0, stk = 0x101816018, env = (nil), pcicaller = (nil)), line 2908 in "mal_interpreter.c" [7] callMAL(cntxt = 0xffffffff7f352c00, mb = 0x1050d5d98, env = 0xfffffffddabff908, argv = 0xfffffffddabff968, debug = '\0'), line 402 in "mal_interpreter.c" [8] SQLexecutePrepared(c = 0xffffffff7f352c00, be = 0x1050f0ec8, q = 0x104fe1b18), line 1196 in "sql_scenario.c" [9] SQLengineIntern(c = 0xffffffff7f352c00, be = 0x1050f0ec8), line 1249 in "sql_scenario.c" [10] SQLengine(c = 0xffffffff7f352c00), line 1349 in "sql_scenario.c" [11] runPhase(c = 0xffffffff7f352c00, phase = 4), line 363 in "mal_scenario.c" [12] runScenarioBody(c = 0xffffffff7f352c00), line 412 in "mal_scenario.c" [13] runScenario(c = 0xffffffff7f352c00), line 438 in "mal_scenario.c" [14] MSserveClient(dummy = 0xffffffff7f352c00), line 368 in "mal_session.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __pollsys() t@2 a l@2 SERVERlistenThread() LWP suspended in __pollsys() t@3 a l@3 mvc_logmanager() LWP suspended in __pollsys() t@4 b l@4 umem_update_thread() sleep on (unknown) in __lwp_park() t@13 a l@13 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@14 a l@14 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@15 a l@15 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@16 a l@16 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@17 a l@17 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@18 a l@18 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@19 a l@19 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@20 a l@20 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@21 a l@21 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@22 a l@22 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@23 a l@23 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@24 a l@24 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@25 a l@25 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@26 a l@26 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@27 a l@27 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() t@28 a l@28 runDFLOWworker() sleep on 0x101ea9a48 in __lwp_park() o> t@212 a l@212 ?() signal SIGSEGV in temp_create() With Feb2010 release, I managed to load a much larger database without a crash. I will try loading this smaller data set again with the Feb2010 release and report what happens. In the meantime, can you give me some suggestions? Thanks. Hering

2 1

[MonetDB-users] Feb2010-SP1/Fedora 12/Ubuntu 9.10/Windows - creating output problem
by dariuszs 21 Apr '10

21 Apr '10

Hi, It looks like the same problem exists no matter what the OS (Fedora 12 or Ubuntu 9.10 or Windows) and this worked in Nov2009-SP1 release. When you try: 'copy select * from table1 limit 1000 into '/tmp/output.txt' You get: sql>copy select * from plk100 limit 1000 into '/tmp/output.txt'; MAPI = monetdb@localhost:50000 ACTION= read_line QUERY = copy select * from plk100 limit 1000 into '/tmp/output.txt'; ERROR = !Connection terminated Timer 1105.876 msec You have mail in /var/spool/mail/root [root@monetdb ~]# [root@monetdb /]# mserver5 --version MonetDB server v5.18.3 (64-bit), based on kernel v1.36.3 (64-bit oids) Copyright (c) 1993-July 2008 CWI Copyright (c) August 2008-2010 MonetDB B.V., all rights reserved Visit http://monetdb.cwi.nl/ for further information Found 47.3GiB available memory, 16 available cpu cores Configured for prefix: /usr Libraries: libpcre: 7.8 2008-09-05 (compiled with 7.8) openssl: OpenSSL 1.0.0-beta4 10 Nov 2009 (compiled with OpenSSL 1.0.0-fips-beta4 10 Nov 2009) libxml2: 2.7.6 (compiled with 2.7.6) Compiled by: mockbuild@ (x86_64-redhat-linux-gnu) Compilation: gcc -O2 -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O6 -fomit-frame-pointer -finline-functions -falign-loops=4 -falign-jumps=4 -falign-functions=4 -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -ftree-vectorize Linking : ld -IPA -m elf_x86_64 Please help. Thanks. Dariusz.

1 0

[MonetDB-users] monetdb/merovingian
by dariuszs 20 Apr '10

20 Apr '10

Hi, I've got this messages after rebooting the server and trying to start merovingian again: unable to open '/var/run/MonetDB/merovingian.pid' for writing: No such file or directory Software: Ubuntu 9.10 MonetDB server v5.18.3 (64-bit), based on kernel v1.36.3 (64-bit oids) Please help. Dariusz.

5 12

[MonetDB-users] Python Error
by Matthew Jones 20 Apr '10

20 Apr '10

Hey folks, I'm seeing an error in the Python API. When connecting to a remote Monet instance with the python client and setting the cursor's arraysize to something significant (100, as an example) then I get the following error: Traceback (most recent call last): File "afile.py", line 9, in <module> cur.execute("SELECT max(val), otherval" File "build/bdist.linux-x86_64/egg/monetdb/sql/cursors.py", line 203, in execute File "build/bdist.linux-x86_64/egg/monetdb/sql/cursors.py", line 445, in __store_result File "build/bdist.linux-x86_64/egg/monetdb/sql/cursors.py", line 529, in __parse_tuple File "build/bdist.linux-x86_64/egg/monetdb/sql/cursors.py", line 569, in __exception_handler monetdb.monetdb_exceptions.InterfaceError: length of row doesn't match header This doesn't happen when the client is used locally on the machine running the database. I will open a bug about this, also. It prevents the .arraysize cursor property from being used remotely. It's default value is 1, which causes the server to take a ridiculously long time to send back large data sets. 73, Matthew W. Jones (KI4ZIB) http://matburt.net

2 1