March 2016 - users-list

UDF returning 0 as a result
by Shmagi Kavtaradze 30 Mar '16

30 Mar '16

I wrote a function bitand. When I do "select bitand(1111,1010);" it gives "0" instead of "0.5". My function: --UDF.c-- str UDFbitand(long long int a, long long b) { long long int weirdAnd(unsigned int a, unsigned int b) { long long int result = 0; int coef = 1; while (a || b) { result += ((a % 10) && (b % 10)) * coef; coef *= 10; a /= 10; b /= 10; } return result; } long long int temp = weirdAnd(a, b); long long int temp2 = weirdAnd(a, b); int length; int count; while (temp != 0) { temp/=10; length++; } while (temp2 != 0) { if (temp2 % 10 == 1) count++; temp2 /= 10; } float final = count/(float)length; return MAL_SUCCEED; } --UDF.mal-- command bitand(a:lng,b:lng):flt address UDFbitand comment "bitand"; --80_UDF.sql-- create function bitand(a BIGINT,b BIGINT) returns REAL external name udf.bitand; When I test my C code in netbeans it works as supposed. Any ideas? Thanks in advance.

3 3

Temporary duplicated rows
by Alex Manaev 30 Mar '16

30 Mar '16

Hi, I have been faced with strange behavior. Sometimes after update that changes field "status", a select query returns multiple identical rows. sql>select * from morgoth_reportquery where not status = 2 and id = 9472 order by id desc limit 5; +------+------+-----------------------------+----------------------------+----------------------------+------+-----------------------------+-----------------------------+------+------+------+------+ | id | repo | name | created_date | ready_date | stat | hash | params | user | appr | temp | noti | : : rt_i : : : : us : : : _id : oved : late : fica : : : d : : : : : : : : : _id : tion : : : : : : : : : : : : : _ema : : : : : : : : : : : : : ils : +======+======+=============================+============================+============================+======+=============================+=============================+======+======+======+======+ | 9472 | 13 | Ежемесячные отчеты: Медиате | 2015-12-01 12:28:59.000000 | null | 1 | 5f34b8459f4834867a2621f7d6b | - !!python/tuple [from_date | 1 | 0 | 8 | | : : : хнологии 2016-02-01 - 2016- : : : : 65c8a : , 2016-02-01] : : : : : : : : 02-11 : : : : : - !!python/tuple [to_date, : : : : : : : : : : : : : 2016-02-11] : : : : : : : : : : : : : - !!python/tuple [update_me : : : : : : : : : : : : : diainfo, 0] : : : : : : : : : : : : : - !!python/tuple : : : : : : : : : : : : : - agreements... > : : : : | 9472 | 13 | Ежемесячные отчеты: Медиате | 2015-12-01 12:28:59.000000 | null | 1 | 5f34b8459f4834867a2621f7d6b | - !!python/tuple [from_date | 1 | 0 | 8 | | : : : хнологии 2016-02-01 - 2016- : : : : 65c8a : , 2016-02-01] : : : : : : : : 02-11 : : : : : - !!python/tuple [to_date, : : : : : : : : : : : : : 2016-02-11] : : : : : : : : : : : : : - !!python/tuple [update_me : : : : : : : : : : : : : diainfo, 0] : : : : : : : : : : : : : - !!python/tuple : : : : : : : : : : : : : - agreements... > : : : : +------+------+-----------------------------+----------------------------+----------------------------+------+-----------------------------+-----------------------------+------+------+------+------+ 2 tuples (8.446ms) !2 fields truncated! In same time another queries return only one row (normal state) sql>select * from morgoth_reportquery where status = 1 and id = 9472 order by id desc limit 5; +------+------+-----------------------------+----------------------------+----------------------------+------+-----------------------------+-----------------------------+------+------+------+------+ | id | repo | name | created_date | ready_date | stat | hash | params | user | appr | temp | noti | : : rt_i : : : : us : : : _id : oved : late : fica : : : d : : : : : : : : : _id : tion : : : : : : : : : : : : : _ema : : : : : : : : : : : : : ils : +======+======+=============================+============================+============================+======+=============================+=============================+======+======+======+======+ | 9472 | 13 | Ежемесячные отчеты: Медиате | 2015-12-01 12:28:59.000000 | null | 1 | 5f34b8459f4834867a2621f7d6b | - !!python/tuple [from_date | 1 | 0 | 8 | | : : : хнологии 2016-02-01 - 2016- : : : : 65c8a : , 2016-02-01] : : : : : : : : 02-11 : : : : : - !!python/tuple [to_date, : : : : : : : : : : : : : 2016-02-11] : : : : : : : : : : : : : - !!python/tuple [update_me : : : : : : : : : : : : : diainfo, 0] : : : : : : : : : : : : : - !!python/tuple : : : : : : : : : : : : : - agreements... > : : : : +------+------+-----------------------------+----------------------------+----------------------------+------+-----------------------------+-----------------------------+------+------+------+------+ 1 tuple (6.474ms) !1 field truncated! Another queries without filter by field `status` give a normal result (one row). Effect is eliminated in several minutes after update by itself. DBMS : MonetDB v11.21.17 (Jul2015-SP3) OS: CentOS 2.6.32-573.12.1.el6.x86_64 #1 SMP Tue Dec 15 21:19:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Issue was reproduced for the first time with version SP-2. Database was created on SP-1. Issue had not appeared with this version. -- Alexey Manaev, Head of software development CJSC "RUTUBE"

1 0

Controlling --dbextras Using MonetDB(D)
by Vincent Sheffer 29 Mar '16

29 Mar '16

mserver5 has an argument called —dbextras. I prefer to control mserver5 using monetdbd, but I don't see any way of specifying this option in either monetdb or monetdbd. Is there, say, a property that can be set in monetdbd or monetdb. The latter probably makes more sense, as I think I would want to control it at the DB level not the dbfarm level. Thanks, Vince The information transmitted, including any attachments, is intended only for the individual or entity to which it is addressed, and may contain confidential and/or privileged information. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by individuals or entities other than the intended recipient is prohibited, and all liability arising therefrom is disclaimed. If you have received this communication in error, please delete the information from any computer and notify the sender.

1 0

simultaneously-created tables not generating
by Anthony Damico 29 Mar '16

29 Mar '16

i have three clients connected to one mserver. they are simultaneously running these three commands, which share table `z` but not the x or y tables-- CREATE TABLE y1 AS SELECT x1.* FROM x1 LEFT JOIN SELECT col FROM Z ON x1.id = z.id WITH DATA ; CREATE TABLE y2 AS SELECT x2.* FROM x2 LEFT JOIN SELECT col FROM Z ON x2.id = z.id WITH DATA ; CREATE TABLE y3 AS SELECT x3.* FROM x3 LEFT JOIN SELECT col FROM Z ON x3.id = z.id WITH DATA ; when all three commands complete, tables y2 and y3 do not exist if i run the commands sequentially, everything works. am i making a mistake in how sql transactions should behave, or is this potentially a bug that i should figure out how to reproduce for bugzilla? thanks!

2 4

Ways to avoid OOMKiller problem?
by Vijay Krishna 29 Mar '16

29 Mar '16

Hi, We came across this - https://www.monetdb.org/Documentation/OOMkiller and we were thinking on some ways to overcome this situation. 1. Is there any configuration in MonetDB to restrict the maximum RAM usage of the mserver process? 2. Is there any configuration in MonetDB to restrict the maximum RAM used by a single thread? 3. Is there any suggested solution for the OOMKiller problem? If you have explored anything else on this, please share your experience with MonetDB server Memory management. Any help much appreciated. Thanks in advance. Regards, Vijay.

3 3

speed cost of stacking tables that do not need to be stacked
by Anthony Damico 27 Mar '16

27 Mar '16

just some UNION ALL speed tests that others might find useful.. i have one big table for each year of data. the year-tables can be analyzed separately - because all of my desired results are going to be within-year averages and counts. since each table has a single year of data, these two statements give equivalent results: query #1: SELECT * FROM ( ( SELECT yr , AVG( value ) FROM y1 GROUP BY yr ) UNION ALL ( SELECT yr , AVG( value ) FROM y2 GROUP BY yr ) ) AS zzz ; query #2: SELECT yr , AVG( value ) FROM ( ( SELECT yr , value FROM y1 ) UNION ALL ( SELECT yr , value FROM y2 ) ) AS zzz GROUP BY yr ; query #1: 290 seconds query #2: 390 seconds query #1: 22 seconds query #2: 87 seconds fwiw- this would take about 24 hours in anything other than monetdb ;)

1 0

database has crashed (dumped core)
by Shmagi Kavtaradze 25 Mar '16

25 Mar '16

I recomplied monetdb several times (make & make install). Everything was fine. Then I downloaded monetdb_python. It was not able to install and I decided to recompile and install again regular Monetdb, but when I "mclient -u monetdb -d voc" I get error in the log file: 2016-03-25 17:26:18 MSG merovingian[49368]: starting database 'voc', up min/avg/max: 0s/0s/0s, crash average: 0.00 0.00 0.00 (0-0=0) 2016-03-25 17:26:18 MSG voc[49379]: arguments: /usr/local/bin/mserver5 --dbpath=/home/shmagi/db/voc --set merovingian_uri=mapi:monetdb://infdbserv02:50000/voc --set mapi_open=false --set mapi_port=0 --set mapi_usock=/home/shmagi/db/voc/.mapi.sock --set monet_vault_key=/home/shmagi/db/voc/.vaultkey --set gdk_nr_threads=24 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes 2016-03-25 17:26:18 MSG merovingian[49368]: database 'voc' (49379) has crashed (dumped core) 2016-03-25 17:26:18 ERR merovingian[49368]: client error: database 'voc' appears to shut itself down after starting, check monetdbd's logfile for possible hints 2016-03-25 17:26:18 MSG merovingian[49368]: starting database 'voc', up min/avg/max: 0s/0s/0s, crash average: 0.00 0.00 0.00 (0-0=0) 2016-03-25 17:26:19 MSG voc[49382]: arguments: /usr/local/bin/mserver5 --dbpath=/home/shmagi/db/voc --set merovingian_uri=mapi:monetdb://infdbserv02:50000/voc --set mapi_open=false --set mapi_port=0 --set mapi_usock=/home/shmagi/db/voc/.mapi.sock --set monet_vault_key=/home/shmagi/db/voc/.vaultkey --set gdk_nr_threads=24 --set max_clients=64 --set sql_optimizer=default_pipe --set monet_daemon=yes 2016-03-25 17:26:19 MSG merovingian[49368]: database 'voc' (49382) has crashed (dumped core) 2016-03-25 17:26:23 ERR merovingian[49368]: client error: database 'voc' appears to shut itself down after starting, check monetdbd's logfile for possible hints. Any ideas how to fix or delete all files of Monetdb to install from the scratch?

1 0

Delete monetdb
by Shmagi Kavtaradze 25 Mar '16

25 Mar '16

Sorry for a stupid questions, but how can I completely delete Monetdb from ubuntu, if I compiled it myself?

4 4

could this be multithreaded? happens after any large import after server stop & restart
by Anthony Damico 25 Mar '16

25 Mar '16

it is dreadfully slow on windows. thanks all # MonetDB 5 server v11.21.13 "Jul2015-SP2" # Serving database 'marketscan', using 40 threads # Compiled for x86_64-pc-winnt/64bit with 64bit OIDs dynamically linked # Found 223.875 GiB available main-memory. # Copyright (c) 1993-July 2008 CWI. # Copyright (c) August 2008-2015 MonetDB B.V., all rights reserved # Visit http://www.monetdb.org/ for further information # Listening for connection requests on mapi:monetdb://127.0.0.1:50100/ # Start processing logs sql/sql_logs version 52200 # Start reading the write-ahead log 'sql_logs\sql\log.14' # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (0% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (1% done) # still reading write-ahead log "sql_logs\sql\log.14" (2% done) # still reading write-ahead log "sql_logs\sql\log.14" (2% done) # still reading write-ahead log "sql_logs\sql\log.14" (2% done) # still reading write-ahead log "sql_logs\sql\log.14" (2% done) # still reading write-ahead log "sql_logs\sql\log.14" (2% done) # still reading write-ahead log "sql_logs\sql\log.14" (3% done) # still reading write-ahead log "sql_logs\sql\log.14" (3% done) # still reading write-ahead log "sql_logs\sql\log.14" (3% done) # still reading write-ahead log "sql_logs\sql\log.14" (3% done) # still reading write-ahead log "sql_logs\sql\log.14" (3% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (4% done) # still reading write-ahead log "sql_logs\sql\log.14" (5% done) # still reading write-ahead log "sql_logs\sql\log.14" (5% done) # still reading write-ahead log "sql_logs\sql\log.14" (5% done) # still reading write-ahead log "sql_logs\sql\log.14" (5% done) # still reading write-ahead log "sql_logs\sql\log.14" (5% done) # still reading write-ahead log "sql_logs\sql\log.14" (6% done) # still reading write-ahead log "sql_logs\sql\log.14" (6% done) # still reading write-ahead log "sql_logs\sql\log.14" (6% done) # still reading write-ahead log "sql_logs\sql\log.14" (6% done) # still reading write-ahead log "sql_logs\sql\log.14" (6% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (7% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (8% done) # still reading write-ahead log "sql_logs\sql\log.14" (9% done) # still reading write-ahead log "sql_logs\sql\log.14" (9% done) # still reading write-ahead log "sql_logs\sql\log.14" (9% done) # still reading write-ahead log "sql_logs\sql\log.14" (9% done) # still reading write-ahead log "sql_logs\sql\log.14" (9% done) # still reading write-ahead log "sql_logs\sql\log.14" (10% done) # still reading write-ahead log "sql_logs\sql\log.14" (10% done) # still reading write-ahead log "sql_logs\sql\log.14" (10% done) # still reading write-ahead log "sql_logs\sql\log.14" (10% done) # still reading write-ahead log "sql_logs\sql\log.14" (10% done) # still reading write-ahead log "sql_logs\sql\log.14" (11% done) # still reading write-ahead log "sql_logs\sql\log.14" (11% done) # still reading write-ahead log "sql_logs\sql\log.14" (11% done) # still reading write-ahead log "sql_logs\sql\log.14" (11% done) # still reading write-ahead log "sql_logs\sql\log.14" (12% done) # still reading write-ahead log "sql_logs\sql\log.14" (12% done) # still reading write-ahead log "sql_logs\sql\log.14" (12% done) # still reading write-ahead log "sql_logs\sql\log.14" (12% done) # still reading write-ahead log "sql_logs\sql\log.14" (12% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (13% done) # still reading write-ahead log "sql_logs\sql\log.14" (14% done) # still reading write-ahead log "sql_logs\sql\log.14" (14% done) # still reading write-ahead log "sql_logs\sql\log.14" (14% done) # still reading write-ahead log "sql_logs\sql\log.14" (14% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (15% done) # still reading write-ahead log "sql_logs\sql\log.14" (16% done) # still reading write-ahead log "sql_logs\sql\log.14" (16% done) # still reading write-ahead log "sql_logs\sql\log.14" (16% done) # still reading write-ahead log "sql_logs\sql\log.14" (16% done) # still reading write-ahead log "sql_logs\sql\log.14" (16% done) # still reading write-ahead log "sql_logs\sql\log.14" (17% done) # still reading write-ahead log "sql_logs\sql\log.14" (17% done) # still reading write-ahead log "sql_logs\sql\log.14" (18% done) # still reading write-ahead log "sql_logs\sql\log.14" (18% done) # still reading write-ahead log "sql_logs\sql\log.14" (18% done) # still reading write-ahead log "sql_logs\sql\log.14" (19% done) # still reading write-ahead log "sql_logs\sql\log.14" (19% done) # still reading write-ahead log "sql_logs\sql\log.14" (20% done) # still reading write-ahead log "sql_logs\sql\log.14" (20% done) # still reading write-ahead log "sql_logs\sql\log.14" (20% done) # still reading write-ahead log "sql_logs\sql\log.14" (21% done) # still reading write-ahead log "sql_logs\sql\log.14" (21% done) # still reading write-ahead log "sql_logs\sql\log.14" (22% done) # still reading write-ahead log "sql_logs\sql\log.14" (22% done) # still reading write-ahead log "sql_logs\sql\log.14" (22% done) # still reading write-ahead log "sql_logs\sql\log.14" (23% done) # still reading write-ahead log "sql_logs\sql\log.14" (23% done) # still reading write-ahead log "sql_logs\sql\log.14" (23% done) # still reading write-ahead log "sql_logs\sql\log.14" (24% done) # still reading write-ahead log "sql_logs\sql\log.14" (24% done) # still reading write-ahead log "sql_logs\sql\log.14" (24% done) # still reading write-ahead log "sql_logs\sql\log.14" (24% done) # still reading write-ahead log "sql_logs\sql\log.14" (25% done) # still reading write-ahead log "sql_logs\sql\log.14" (25% done) # still reading write-ahead log "sql_logs\sql\log.14" (25% done) # still reading write-ahead log "sql_logs\sql\log.14" (26% done) # still reading write-ahead log "sql_logs\sql\log.14" (26% done) # still reading write-ahead log "sql_logs\sql\log.14" (27% done) # still reading write-ahead log "sql_logs\sql\log.14" (27% done) # still reading write-ahead log "sql_logs\sql\log.14" (27% done) # still reading write-ahead log "sql_logs\sql\log.14" (28% done) # still reading write-ahead log "sql_logs\sql\log.14" (28% done) # still reading write-ahead log "sql_logs\sql\log.14" (28% done) # still reading write-ahead log "sql_logs\sql\log.14" (28% done) # still reading write-ahead log "sql_logs\sql\log.14" (29% done) # still reading write-ahead log "sql_logs\sql\log.14" (30% done) # still reading write-ahead log "sql_logs\sql\log.14" (30% done) # still reading write-ahead log "sql_logs\sql\log.14" (31% done) # still reading write-ahead log "sql_logs\sql\log.14" (31% done) # still reading write-ahead log "sql_logs\sql\log.14" (31% done) # still reading write-ahead log "sql_logs\sql\log.14" (32% done) # still reading write-ahead log "sql_logs\sql\log.14" (32% done) # still reading write-ahead log "sql_logs\sql\log.14" (32% done) # still reading write-ahead log "sql_logs\sql\log.14" (33% done) # still reading write-ahead log "sql_logs\sql\log.14" (33% done) # still reading write-ahead log "sql_logs\sql\log.14" (34% done) # still reading write-ahead log "sql_logs\sql\log.14" (34% done) # still reading write-ahead log "sql_logs\sql\log.14" (34% done) # still reading write-ahead log "sql_logs\sql\log.14" (35% done) # still reading write-ahead log "sql_logs\sql\log.14" (35% done) # still reading write-ahead log "sql_logs\sql\log.14" (35% done) # still reading write-ahead log "sql_logs\sql\log.14" (35% done) # still reading write-ahead log "sql_logs\sql\log.14" (36% done) # still reading write-ahead log "sql_logs\sql\log.14" (36% done) # still reading write-ahead log "sql_logs\sql\log.14" (36% done) # still reading write-ahead log "sql_logs\sql\log.14" (36% done) # still reading write-ahead log "sql_logs\sql\log.14" (37% done) # still reading write-ahead log "sql_logs\sql\log.14" (37% done) # still reading write-ahead log "sql_logs\sql\log.14" (37% done) # still reading write-ahead log "sql_logs\sql\log.14" (38% done) # still reading write-ahead log "sql_logs\sql\log.14" (39% done) # still reading write-ahead log "sql_logs\sql\log.14" (40% done) # still reading write-ahead log "sql_logs\sql\log.14" (41% done) # still reading write-ahead log "sql_logs\sql\log.14" (42% done) # still reading write-ahead log "sql_logs\sql\log.14" (44% done) # still reading write-ahead log "sql_logs\sql\log.14" (45% done) # still reading write-ahead log "sql_logs\sql\log.14" (46% done) # still reading write-ahead log "sql_logs\sql\log.14" (47% done) # still reading write-ahead log "sql_logs\sql\log.14" (48% done) # still reading write-ahead log "sql_logs\sql\log.14" (49% done) # still reading write-ahead log "sql_logs\sql\log.14" (50% done) # still reading write-ahead log "sql_logs\sql\log.14" (50% done) # still reading write-ahead log "sql_logs\sql\log.14" (51% done) # still reading write-ahead log "sql_logs\sql\log.14" (52% done) # still reading write-ahead log "sql_logs\sql\log.14" (53% done) # still reading write-ahead log "sql_logs\sql\log.14" (54% done) # still reading write-ahead log "sql_logs\sql\log.14" (55% done) # still reading write-ahead log "sql_logs\sql\log.14" (55% done) # still reading write-ahead log "sql_logs\sql\log.14" (56% done) # still reading write-ahead log "sql_logs\sql\log.14" (57% done) # still reading write-ahead log "sql_logs\sql\log.14" (57% done) # still reading write-ahead log "sql_logs\sql\log.14" (58% done) # still reading write-ahead log "sql_logs\sql\log.14" (59% done) # still reading write-ahead log "sql_logs\sql\log.14" (59% done) # still reading write-ahead log "sql_logs\sql\log.14" (60% done) # still reading write-ahead log "sql_logs\sql\log.14" (60% done)

2 2

Announcement: New Jul2015-SP3 Bugfix release of MonetDB suite
by Sjoerd Mullender 25 Mar '16

25 Mar '16

The MonetDB team at CWI/MonetDB BV is pleased to announce the Jul2015-SP3 bugfix release of the MonetDB suite of programs. More information about MonetDB can be found on our website at <http://www.monetdb.org/>. For details on this release, please see the release notes at <http://www.monetdb.org/Downloads/ReleaseNotes>. As usual, the download location is <http://dev.monetdb.org/downloads/>. Jul 2015-SP3 bugfix release MonetDB5 Server * Fixed potential crash in MAL debugger when accessing BATs by index. Functionality dropped as it is also a security leak. Bug Fixes * 2972: SQL URL functionality contains errors * 3549: bulk string operations very slow * 3881: Server crashes on bulk load * 3890: Window function + group by in subselect, rel2bin_project: Assertion `0' failed * 3891: MonetDB crashes when executing SQL with window function * 3900: null handling in some sql statements is incorrect * 3906: Multi-column 1-N table-function with mitosis produces different column counts * 3908: LEFT JOIN with OR conditions triggers assertion * 3909: Incorrect column name in OR condition of LEFT JOIN crashes mserver * 3910: COPY INTO table (column1, column2) got wrong result * 3912: When table/column names conflicts, data ends in multiple tables! * 3917: Date difference returns month_interval instead of day_interval * 3918: MonetDB.R version 1.0.1 incorrectly constructs the batfile script * 3919: Table conflict when the table name and fields are identical * 3921: Creating a table from a complex query crashes mserver or triggers assertion * 3922: AVG( column ) returns NaN rather than Inf when column contains Inf * 3928: When killing a virtual machine, sql_logs/sql/log is empty * 3930: Wrong typecast on character columns in prepared statements when using Umlaute * 3932: CASE expressions with constants are not evaluated correctly * 3933: replace "exit" by "throw new Exception" * 3937: bad BAT properties with binary copy into and NULL values * 3938: Wrong error message on violating foreign key constraint * 3940: Date calculation and comparison produce wrong result * 3941: Wrong coercion priority * 3948: SQL: select * from sys.sys.table_name; is accepted but should return an error * 3951: extern table_funcs not visible from Windows DLL for extensions like vaults (crashes) * 3952: Stream table gives segfault * 3953: MIN/MAX of a UUID column produces wrong results * 3954: Consolidate table assertion error * 3955: (incorrect) MAL loop instead of manifold triggered by simple change in target list

1 0