- developers-list - monetdb.org

[Monetdb-developers] Mserver hangs on quit(); on RedHat 8.0 (psyche)
by Stefan.Manegold＠cwi.nl 15 Dec '04

15 Dec '04

Hi again, with the latest MonetDB 4.5.0 on RedHat 8.0 (psyche), Jan (F.;-) experiences a "consistently" hang of the Mserver, once he tries to quit it. See below for details. It did work with older versions of MonetDB, but we hanven't locate more precisely, yet, since which version/code change the hang occurs. My question is, has anybody else ever experienced similar problems? I now vaguely recall, that there might have been some related issue, but I don't remember the details, yet --- could someone who does refresh my mind? Thank you very much in advance! Stefan Forwarded message: > From flokstra(a)cs.utwente.nl Wed Dec 15 09:30:02 2004 > X-Sieve: CMU Sieve 2.2 > Content-Type: text/plain; > charset="us-ascii" > From: Jan Flokstra <flokstra(a)cs.utwente.nl> > Organization: University Twente Enschede > To: Stefan.Manegold(a)cwi.nl (Stefan Manegold) > Subject: Re: Monet problem > Date: Wed, 15 Dec 2004 09:27:45 +0100 > User-Agent: KMail/1.4.3 > References: <20041213155606.9656241044(a)draco.ins.cwi.nl> > In-Reply-To: <20041213155606.9656241044(a)draco.ins.cwi.nl> > Cc: "Peter Boncz" <P.Boncz(a)cwi.nl> > MIME-Version: 1.0 > Old-Content-Transfer-Encoding: quoted-printable > Message-Id: <200412150927.47729.flokstra(a)cs.utwente.nl> > X-Spam-Score: -4.9 () BAYES_00 > X-Scanned-By: milter-spamc/0.25.320 (styx.cwi.nl [192.16.191.21]); Wed, 15 Dec 2004 09:28:11 +0100 > X-Scanned-By: MIMEDefang 2.44 > X-Spam-Flag: NO > X-Spam-Status: NO, hits=0.00 required=5.00 > X-Spam-Level: > X-Spam-Report: Content analysis details: (0.0 points, 5.0 required) > Tests (points, rulename, description): > ____ > X-Virus-Scanned: by cwi.nl (CWI/$Revision: 1.25 $) > Content-Transfer-Encoding: 8bit > > Hi Stefan, > > I am using Redhat Linux, version (uname -a) > > Linux psyche 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux > > and the default compilers on this version. I made an strace of the Mserver > and got the following output (just the tail) > It looks it never returns from the rt_sigsuspend() syscall and this is > indeed very strange! > > Regards, Jan. > > > brk(0x8175000) = 0x8175000 > brk(0x8177000) = 0x8177000 > brk(0x8178000) = 0x8178000 > brk(0x8179000) = 0x8179000 > brk(0x817b000) = 0x817b000 > brk(0x817d000) = 0x817d000 > brk(0x817f000) = 0x817f000 > brk(0x8180000) = 0x8180000 > brk(0x8181000) = 0x8181000 > brk(0x8182000) = 0x8182000 > brk(0x8183000) = 0x8183000 > brk(0x8185000) = 0x8185000 > brk(0x8186000) = 0x8186000 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x4006c4eb) = 4096 > open("/usr/local/flokstra/lib/MonetDB/trans.mil", O_RDONLY|O_LARGEFILE) = 8 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > fstat64(8, {st_mode=S_IFREG|0755, st_size=70, ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(8, "# This module is generated using"..., 4096) = 70 > read(8, "", 4096) = 0 > close(8) = 0 > munmap(0x4045f000, 4096) = 0 > close(7) = 0 > open("/usr/local/flokstra/lib/MonetDB", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7 > fstat64(7, {st_mode=S_IFDIR|0755, st_size=8192, ...}) = 0 > fcntl64(7, F_SETFD, FD_CLOEXEC) = 0 > lseek(7, 0, SEEK_SET) = 0 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 4096 > getdents64(0x7, 0x80a1b90, 0x1000, 0x400709c6) = 2504 > open("/usr/local/flokstra/lib/MonetDB/lib_trans.so", O_RDONLY) = 8 > read(8, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\314\16"..., 1024) = > 1024 > fstat64(8, {st_mode=S_IFREG|0755, st_size=78034, ...}) = 0 > old_mmap(NULL, 16136, PROT_READ|PROT_EXEC, MAP_PRIVATE, 8, 0) = 0x419f7000 > mprotect(0x419fa000, 3848, PROT_NONE) = 0 > old_mmap(0x419fa000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 8, > 0x2000) = 0x419fa000 > close(8) = 0 > write(1, "MonetDB>", 8MonetDB>) = 8 > fstat64(0, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0 > mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = > 0x4045f000 > read(0, quit(); > "quit();\n", 1024) = 8 > write(6, "\200\20G@\2\0\0\0\0\0\0\0\222\253\0@\304\363\377\277\300"..., 148) = > 148 > rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 > rt_sigsuspend([] > > > -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] "pseudo" nested BATs
by Stefan.Manegold＠cwi.nl 15 Dec '04

15 Dec '04

Hi MonetDB developers and users, sorry for this "blunt" posting, but I thought, the problem, respectively the solution/recommendation that will hopefully be initiated by this question, might be interesting for some more of you: Triggered by a question from Agustin, I noticed that I (believe it or not ;-) apparently lack some knowledge of / experiences with MonetDB/MIL: Consider you have a variable "a" holding a (possible transient) BAT, and another variable "b" holding a second BAT, which happens to be a view of the first one. Both BATs haven't been baptized ("rename()"), yet; hence they still hold there default names: var a := new(void,int).seqbase(0(a)0).insert(nil,1).insert(nil,2).access(BAT_READ); var b := reverse(a); print(a); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(b); #-----------------# # t tmp_29 # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] Then, these BATs should be gathered in a "container"-BAT. Since (persistent) nested BATs have disappeared (for good reasons!), we do this by gathering the BAT's name in the container: var c := new(void,str).seqbase(10@0); c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] Since the second BAT is only a view of the first one, they share not only the same memory/storage, but also the same (bbp-)name; hence, they are not distinguishable by (only) their (bbp-)names, and thus the container c actually contains the first BAT twice iso each BAT once: print(bat(fetch(c,0))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,1))); #-----------------# # h tmp_29 # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bbpname(a)); [ "tmp_29" ] print(bbpname(b)); [ "tmp_29" ] Obviously, the problem can be solved/avoided by baptizing the two BATs, and hence making them unique "individuals": rename(a,"BAT_a"); rename(b,"BAT_b"); print(bbpname(a)); [ "BAT_a" ] print(bbpname(b)); [ "BAT_b" ] c.insert(nil,bbpname(a)).insert(nil,bbpname(b)); print(c); #-------------------------# # h tmp_28 # name # void str # type #-------------------------# [ 10@0, "tmp_29" ] [ 11@0, "tmp_29" ] [ 12@0, "BAT_a" ] [ 13@0, "BAT_b" ] print(bat(fetch(c,0))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,1))); !ERROR: interpret_params: print(param 1): invalid BAT. print(bat(fetch(c,2))); #-----------------# # h BAT_b # name # void int # type #-----------------# [ 0@0, 1 ] [ 1@0, 2 ] print(bat(fetch(c,3))); #-----------------# # t BAT_b # name # int void # type #-----------------# [ 1, 0@0 ] [ 2, 1@0 ] My question is now: - Is this the only solution, or am I just not aware of another command iso bbpname() that would return unique "default" name for non-renamed view? Of course, given the fact that only MonetDB itself has control over the default "tmp_*" names, it is always recommendable to assign names that you can control yourself, whenever you use a BAT's name as its only reference... Stefan -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

2 1

Re: [Monetdb-developers] php
by Arjan Scherpenisse 08 Sep '04

08 Sep '04

De extension_dir .ini variabele kan maar 1 pad bevatten, helaas niet meerdere paden gescheiden door ':'s :(... En de waarde van extension_dir alleen op MONETDB_PREFIX/share/MonetDB/php zetten lijkt me ook geen optie omdat dan andere PHP applicaties gaan breken... Arjen P. de Vries wrote: > hoi Arjan, > > De variable extension_dir kan ook gezet worden in php.ini of httpd.conf > (volgens http://aspn.activestate.com/ASPN/docs/PHP/function.ini-set.html) > > misschien dat het dan geen probleem is, als het monet-path wordt toegevoegd > aan php.ini (even ervanuitgaand dat dat ook per-user kan)? > > Groetjes, > > Arjen > > | De monetdb.so file moet echt in PHP_EXTENSION_DIR staan, anders kan de > | module niet worden gebruikt binnen PHP. Hoe zullen we dit fixen? Goed > | documenteren, of mischien een phpinstall.sh scriptje toevoegen wat het > | voor je regelt (wat als root moet worden uitgevoerd)? > | -- > | Arjan Scherpenisse > | > | Centrum voor Wiskunde en Informatica, > | Amsterdam, the Netherlands > | > | > | ------------------------------------------------------- > | This SF.Net email is sponsored by BEA Weblogic Workshop > | FREE Java Enterprise J2EE developer tools! > | Get your free copy of BEA WebLogic Workshop 8.1 today. > | http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > | _______________________________________________ > | Monetdb-developers mailing list > | Monetdb-developers(a)lists.sourceforge.net > | https://lists.sourceforge.net/lists/listinfo/monetdb-developers > | -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 2

[Monetdb-developers] php
by Arjan Scherpenisse 08 Sep '04

08 Sep '04

De monetdb.so file moet echt in PHP_EXTENSION_DIR staan, anders kan de module niet worden gebruikt binnen PHP. Hoe zullen we dit fixen? Goed documenteren, of mischien een phpinstall.sh scriptje toevoegen wat het voor je regelt (wat als root moet worden uitgevoerd)? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0

[Monetdb-developers] mapi: how to check mil query on errors?
by Arjan Scherpenisse 19 Aug '04

19 Aug '04

For SQL code, I check now with: hdl = mapi_query(mid, "very wrong query."); while( mapi_next_result(hdl) ) { if (mapi_result_error(hdl)) { // error handling here how to do this equivalent for mil queries? Or dont we need mil queries anymore? My personal opinion is to keep doing it the old way for mil-type queries (if (mapi_error()) etc), but that does not seem to work... -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] Weird server/client behaviour?
by Fabian 18 Aug '04

18 Aug '04

Because I don't really know if it's a bug on whose side, I decided to at least put in the issue via this list. When I try to load the VOC dataset using the JdbcClient with the new -Xbatching flag, the client hangs when it wants to send its last batch. I'm batching in chunks of 8000 statements. Research pointed out that the Java streams are trying to write data to monet, but it simply can't write it, and locks. I pinned down the problem to be in the very low level code regions which are outside of the Java reachable scope and go into the level of the operating system. It just cannot write to the stream. Monet on the other hand seems to be waiting for data. When I use a smaller dataset the batching goes fine. Any clues on what to look for? GDB couldn't help me out much.

1 0

[Monetdb-developers] Re: DBI
by Arjan Scherpenisse 10 Aug '04

10 Aug '04

Martin Kersten wrote: > That's a real pity. Would it require many changes? > Otherwise, we would have to invalidate the perl API > in the upcoming release. I dont know if it requires many changes. The reply-parsing code in monet.pm looks quite 'unstable' to me; I have not found the problem yet. In my opinion it would be better to base programming language APIs on the existing libMapi C code. That way protocol changes etc. only need to be implemented in a single place... Anyway I do not think I have much time to look further into this, I have a thesis to finish ;-) Arjan > > Arjan Scherpenisse wrote: > >> Martin Kersten wrote: >> >>> Does it run against our current DBI? >> >> >> >> No, it does not run. Connecting works, and executing queries too, but >> fetching results from queries does not. >> >> It is likely that this is the case because it is a pure-perl >> implementation and it is not up-to-date with some of the changes in >> the protocol lately. >> >> Even the simple test script which comes with the current >> implementation does not run anymore :( >> >> Arjan >> > -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

2 1

[Monetdb-developers] How to create Tests
by Stefan.Manegold＠cwi.nl 15 Jul '04

15 Jul '04

Hi, I haven't had any time, yet, to prepare a real HowTo on this topic, but for those of you who are interested, here's a trace of what I did to make Arjan's sql/src/test/bugs/bug-sf-990096.sql script into a "real" test. Stefan ======== 14:51:06 manegold@draco:~/Monet/4.3/sql $ echo 'bug-sf-990096' >> src/test/bugs/Tests/All 14:51:13 manegold@draco:~/Monet/4.3/sql $ echo '$RELSRCDIR/../bug-sf-990096.sql' > src/test/bugs/Tests/bug-sf-990096.sql.src 14:51:21 manegold@draco:~/Monet/4.3/sql $ Mtest_sql src/test/bugs bug-sf-990096 IGNORE = ^# TIMEOUT = 60 RECURSIVE = 0 CONTEXT = -C1 ACCURACY = 1 MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ SQLCLIENT = MapiClient --language=sql MAPICLIENT = MapiClient X100CLIENT = x100run_mapi MAPIPORT = 40891 SQLPORT = 52395 GDK_DEBUG = 10 MONET_MOD_PATH = /var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB SQL_LOGDIR = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log GDK_DBFARM = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm setMONET_MOD_PATH = --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" MAPI_MIL = /var/tmp/_BUILD_MONET_GNU_32_d__/src/mapi/mapi.mil SQL_SERVER = sql_server SQL_SERVER_MIL = /var/tmp/_BUILD_SQL_GNU_32_d__/src/backends/monet4/sql_server.mil MDIFF = /var/tmp/_PREFIX__GNU_32_d__/bin/Mdiff : Mdiff MSERVER = /var/tmp/_PREFIX__GNU_32_d__/bin/Mserver : Mserver "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --debug=10 --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" --set "gdk_dbfarm=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm" --set "sql_logdir=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log" --set mapi_port=40891 --set sql_port=52395 --set monet_prompt= --trace MTIMEOUT = /var/tmp/_PREFIX__GNU_32_d__/bin/Mtimeout : Mtimeout -timeout 60 MSHUTDOWN = /var/tmp/_PREFIX__GNU_32_d__/bin/Mshutdown.py : Mshutdown.py "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 PYTHON = /usr/bin/python : python SQL_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=52395 X100_CLIENT = : x100run_mapi -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 MAPI_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=40891 Bits: 32bit Modules: ('main', 'kernel', '_kernel', 'arith', '_arith', 'str', '_str', 'uchr', '_uchr', 'bat', '_bat', 'algebra', '_algebra', 'sys', '_sys', 'trans', '_trans', 'streams', 'xtables', 'mkey', 'profiler', 'aggr', 'aggrX3', 'alarm', 'ascii_io', 'bat_arith', 'blob', 'decimal', 'enum', 'lock', 'mmath', 'monettime', 'radix', 'stats', 'tcpip', 'unix', 'url', 'counters', 'pcl', 'bitset', 'bitvector', 'cluster', 'iterator', 'malalgebra', 'mel', 'mprof', 'oo7', 'qt', 'salgebra', 'tpcd', 'vector', 'wisc', 'ddbench', 'bat_mmath', 'bat_cast', 'array', 'color', 'image', 'txtsim', 'calib', 'mapi', 'sql_server', 'pf_support') Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. 14:51:29> src/test/bugs/bug-sf-990096.sql (<=240s) ... 1.167s bug-sf-990096.stable.out.FILTERED and bug-sf-990096.test.out.FILTERED differ SIGNIFICANTLY! bug-sf-990096.stable.err.FILTERED and bug-sf-990096.test.err.FILTERED differ SIGNIFICANTLY! !ERROR: Testing FAILED SIGNIFICANTLY ! 1 out of 1 tests produced SIGNIFICANTLY different output First, check the testing results in /var/tmp/_PREFIX__GNU_32_d__/mTests/index.html ! Then, fix the problems by: - fixing sources and test scripts - fixing stable output by hand - approving test output by Mapprove.py (cf. Mapprove.py -?) After that, re-run Mtest. 14:51:32 manegold@draco:~/Monet/4.3/sql $ Mapprove_sql src/test/bugs bug-sf-990096 FORCE = 0 RECURSIVE = 0 EXTENSION = ['out', 'err'] SYSTEM = MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. Approving src/test/bugs/bug-sf-990096.test.out -> stable.out (creating new file) patching file /ufs/manegold/Monet/4.3/sql/src/test/bugs/Tests/bug-sf-990096.stable.out Approving src/test/bugs/bug-sf-990096.test.err -> stable.err (creating new file) Mapprove.py Warning: Skipping new (error) message: "+ERROR = !Column: a.i unknown" patching file /ufs/manegold/Monet/4.3/sql/src/test/bugs/Tests/bug-sf-990096.stable.err First, run 'cvs -q diff to check what you have changed. Then, re-run Mtest.py. In case (some of) the skipped error messages are correct/expected, re-run Mapprove.py with -f to force their approval. 14:51:51 manegold@draco:~/Monet/4.3/sql $ joe src/test/bugs/Tests/bug-sf-990096.stable.??? Processing '/ufs/manegold/.joerc'...done Processing '/ufs/manegold/.joerc'...done File src/test/bugs/Tests/bug-sf-990096.stable.err not changed so no update needed. 14:52:45 manegold@draco:~/Monet/4.3/sql $ diff -u src/test/bugs/Tests/bug-sf-990096.stable.out{~,} --- src/test/bugs/Tests/bug-sf-990096.stable.out~ 2004-07-13 14:52:43.000000000 +0200 +++ src/test/bugs/Tests/bug-sf-990096.stable.out 2004-07-13 14:52:43.000000000 +0200 @@ -27,6 +27,12 @@ # 0, # id [ 1, 1 ] +# i, i # name +# mediumint, mediumint # type +# 1, # tuplecount +# 0, # id +[ 1, 1 ] + # 14:51:31 > # 14:51:31 > Done. # 14:51:31 > 14:52:54 manegold@draco:~/Monet/4.3/sql $ diff -u src/test/bugs/Tests/bug-sf-990096.stable.err{~,} --- src/test/bugs/Tests/bug-sf-990096.stable.err~ 2004-07-13 14:52:36.000000000 +0200 +++ src/test/bugs/Tests/bug-sf-990096.stable.err 2004-07-13 14:52:36.000000000 +0200 @@ -56,10 +56,6 @@ # 14:51:30 > Mtimeout -timeout 60 MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=52395 < bug-sf-990096.sql # 14:51:30 > -MAPI = monetdb@draco:52395 -ACTION= read_into_cache -QUERY = SELECT a.i FROM - # 14:51:31 > # 14:51:31 > Done. 14:52:58 manegold@draco:~/Monet/4.3/sql $ Mtest_sql src/test/bugs bug-sf-990096 IGNORE = ^# TIMEOUT = 60 RECURSIVE = 0 CONTEXT = -C1 ACCURACY = 1 MONET_SOURCE = /ufs/manegold/Monet/4.3/MonetDB MONET_BUILD = /var/tmp/_BUILD_MONET_GNU_32_d__ MONET_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ TSTSRCBASE = /ufs/manegold/Monet/4.3/sql TSTBLDBASE = /var/tmp/_BUILD_SQL_GNU_32_d__ TSTTRGBASE = /var/tmp/_PREFIX__GNU_32_d__ SQL_PREFIX = /var/tmp/_PREFIX__GNU_32_d__ SQLCLIENT = MapiClient --language=sql MAPICLIENT = MapiClient X100CLIENT = x100run_mapi MAPIPORT = 46225 SQLPORT = 53058 GDK_DEBUG = 10 MONET_MOD_PATH = /var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB SQL_LOGDIR = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log GDK_DBFARM = /var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm setMONET_MOD_PATH = --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" MAPI_MIL = /var/tmp/_BUILD_MONET_GNU_32_d__/src/mapi/mapi.mil SQL_SERVER = sql_server SQL_SERVER_MIL = /var/tmp/_BUILD_SQL_GNU_32_d__/src/backends/monet4/sql_server.mil MDIFF = /var/tmp/_PREFIX__GNU_32_d__/bin/Mdiff : Mdiff MSERVER = /var/tmp/_PREFIX__GNU_32_d__/bin/Mserver : Mserver "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --debug=10 --set "monet_mod_path=/var/tmp/_PREFIX__GNU_32_d__/lib/MonetDB" --set "gdk_dbfarm=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/dbfarm" --set "sql_logdir=/var/tmp/_PREFIX__GNU_32_d__/var/MonetDB/log" --set mapi_port=46225 --set sql_port=53058 --set monet_prompt= --trace MTIMEOUT = /var/tmp/_PREFIX__GNU_32_d__/bin/Mtimeout : Mtimeout -timeout 60 MSHUTDOWN = /var/tmp/_PREFIX__GNU_32_d__/bin/Mshutdown.py : Mshutdown.py "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 PYTHON = /usr/bin/python : python SQL_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient --language=sql -u monetdb -P monetdb --host=draco --port=53058 X100_CLIENT = : x100run_mapi -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 MAPI_CLIENT = /var/tmp/_PREFIX__GNU_32_d__/bin/MapiClient : MapiClient -u monetdb -P monetdb "--config=/var/tmp/_PREFIX__GNU_32_d__/etc/monet.conf" --host=draco --port=46225 Bits: 32bit Modules: ('main', 'kernel', '_kernel', 'arith', '_arith', 'str', '_str', 'uchr', '_uchr', 'bat', '_bat', 'algebra', '_algebra', 'sys', '_sys', 'trans', '_trans', 'streams', 'xtables', 'mkey', 'profiler', 'aggr', 'aggrX3', 'alarm', 'ascii_io', 'bat_arith', 'blob', 'decimal', 'enum', 'lock', 'mmath', 'monettime', 'radix', 'stats', 'tcpip', 'unix', 'url', 'counters', 'pcl', 'bitset', 'bitvector', 'cluster', 'iterator', 'malalgebra', 'mel', 'mprof', 'oo7', 'qt', 'salgebra', 'tpcd', 'vector', 'wisc', 'ddbench', 'bat_mmath', 'bat_cast', 'array', 'color', 'image', 'txtsim', 'calib', 'mapi', 'sql_server', 'pf_support') Running tests ['bug-sf-990096'] in directory /ufs/manegold/Monet/4.3/sql/src/test/bugs. 14:53:17> src/test/bugs/bug-sf-990096.sql (<=240s) ... 1.065s bug-sf-990096.stable.out.FILTERED and bug-sf-990096.test.out.FILTERED differ SIGNIFICANTLY! bug-sf-990096.stable.err.FILTERED and bug-sf-990096.test.err.FILTERED differ SIGNIFICANTLY! !ERROR: Testing FAILED SIGNIFICANTLY ! 1 out of 1 tests produced SIGNIFICANTLY different output First, check the testing results in /var/tmp/_PREFIX__GNU_32_d__/mTests/index.html ! Then, fix the problems by: - fixing sources and test scripts - fixing stable output by hand - approving test output by Mapprove.py (cf. Mapprove.py -?) After that, re-run Mtest. 14:53:19 manegold@draco:~/Monet/4.3/sql $ rm src/test/bugs/Tests/bug-sf-990096.stable.???~ -rw-r----- 1 manegold ins 2807 Jul 13 14:52 src/test/bugs/Tests/bug-sf-990096.stable.err~ -rw-r----- 1 manegold ins 1140 Jul 13 14:52 src/test/bugs/Tests/bug-sf-990096.stable.out~ Delete these 2 files/directories? (y/N) \c y 2 files deleted. 14:53:56 manegold@draco:~/Monet/4.3/sql $ cvs add src/test/bugs/Tests/bug-sf-990096.* cvs add: warning: unrecognized response '' from cvs server cvs add: use 'cvs commit' to add these files permanently 14:54:16 manegold@draco:~/Monet/4.3/sql $ cvs up src/test/bugs/Tests M src/test/bugs/Tests/All M src/test/bugs/Tests/bug-00001.stable.out A src/test/bugs/Tests/bug-sf-990096.sql.src A src/test/bugs/Tests/bug-sf-990096.stable.err A src/test/bugs/Tests/bug-sf-990096.stable.out 14:54:34 manegold@draco:~/Monet/4.3/sql $ cvs diff src/test/bugs/Tests Index: src/test/bugs/Tests/All =================================================================== RCS file: /cvsroot/monetdb/sql/src/test/bugs/Tests/All,v retrieving revision 1.17 diff -u -r1.17 All --- src/test/bugs/Tests/All 24 Jun 2004 15:26:59 -0000 1.17 +++ src/test/bugs/Tests/All 13 Jul 2004 12:54:42 -0000 @@ -25,3 +25,4 @@ bug-sf-975308 bug-sf-978043 bug-sf-978045 +bug-sf-990096 Index: src/test/bugs/Tests/bug-00001.stable.out =================================================================== RCS file: /cvsroot/monetdb/sql/src/test/bugs/Tests/bug-00001.stable.out,v retrieving revision 1.3 diff -u -r1.3 bug-00001.stable.out --- src/test/bugs/Tests/bug-00001.stable.out 20 Jun 2004 21:46:22 -0000 1.3 +++ src/test/bugs/Tests/bug-00001.stable.out 13 Jul 2004 12:54:42 -0000 @@ -60,8 +60,8 @@ [ 1005711, "privileges", 1005548, "", 1 ] [ 1005740, "history", 1005548, "", 1 ] [ 1005778, "env", 1005548, "", 1 ] -[ 1007047, "foo", 1005548, "", 0 ] -[ 1007212, "ff", 1005548, "", 0 ] +[ 1007035, "foo", 1005548, "", 0 ] +[ 1007200, "ff", 1005548, "", 0 ] # i # name # int # type # 2 # tuplecount @@ -91,9 +91,9 @@ [ 1005711, "privileges", 1005548, "", 1 ] [ 1005740, "history", 1005548, "", 1 ] [ 1005778, "env", 1005548, "", 1 ] -[ 1007047, "foo", 1005548, "", 0 ] -[ 1007212, "ff", 1005548, "", 0 ] -[ 1007468, "s4", 1005548, "", 0 ] +[ 1007035, "foo", 1005548, "", 0 ] +[ 1007200, "ff", 1005548, "", 0 ] +[ 1007456, "s4", 1005548, "", 0 ] # i # name # int # type # 1 # tuplecount cvs diff: src/test/bugs/Tests/bug-sf-990096.sql.src is a new entry, no comparison available cvs diff: src/test/bugs/Tests/bug-sf-990096.stable.err is a new entry, no comparison available cvs diff: src/test/bugs/Tests/bug-sf-990096.stable.out is a new entry, no comparison available 14:54:43 manegold@draco:~/Monet/4.3/sql $ ======== -- | Dr. Stefan Manegold | mailto:Stefan.Manegold@cwi.nl | | CWI, P.O.Box 94079 | http://www.cwi.nl/~manegold/ | | 1090 GB Amsterdam | Tel.: +31 (20) 592-4212 | | The Netherlands | Fax : +31 (20) 592-4312 |

1 0

[Monetdb-developers] Auto-commit
by Fabian 04 Jul '04

04 Jul '04

Consider the following multi query statement: (1) update x set somecol = 'newval'; select * form x; (mind the explicit typo in the second query (from)) Now consider this whole statement being sent at once with auto_commit disabled. The second query will fail due to a syntax error and the whole connection will have to be rollbacked. If the error would be reported, and the --- theoretical --- update count would be ignored, there would be no problem at all, I think. However, suppose auto_commit is switched on. Now the scenario brings some problems: 1. the first update is executed, and committed; thus an update count should be returned. 2. the second query fails and generates an error, however this error can't be displayed if the update count is displayed, the statement executes or fails, not partial. As it looks now, using JDBC, a statement has a mutually exclusive result; either success, or failure. The current implementation of auto_commit, commits after each query, I think it should commit after each statement, so the statement as in (1) gets rollbacked as a whole and results in an error, instead of in a result and an error. Is this a reasonable thought of mine, or does it clash with other things? How does ODBC handle this situation?

2 3

[Monetdb-developers] Bus Error?
by Arjan Scherpenisse 01 Jul '04

01 Jul '04

While executing a big query, sometimes I get a Bus error. Now, I've looked up that "This signal is raised when your program accesses memory in an invalid way"; but what i am wondering, is this signal a) A bug in Monet b) A way of Monet telling me that it has run out of memory? -- Arjan Scherpenisse Centrum voor Wiskunde en Informatica, Amsterdam, the Netherlands

1 0