The MonetDB team at CWI/MonetDB BV is pleased to announce a second
release candidate for the upcoming Jan2014 feature release.
Many things have changed in this release compared to the previous
(Feb2013) release (that's why it took so long). For a smooth upgrade I
would urge you to try out this release candidate and to provide feedback
on our bug tracker (http://bugs.monetdb.org).
A number of bugs in the previous release candidate have been fixed.
Among others, packaging errors on Debian and Ubuntu have been fixed, and
a problem with slow startup has been fixed.
The release candidate can be found at
http://dev.monetdb.org/downloads/testing.
--
Sjoerd Mullender
The MonetDB team at CWI/MonetDB BV is pleased to announce a release
candidate for the upcoming Jan2014 feature release.
Many things have changed in this release compared to the previous
(Feb2013) release (that's why it took so long). For a smooth upgrade I
would urge you to try out this release candidate and to provide feedback
on our bug tracker (http://bugs.monetdb.org).
The release candidate can be found at
http://dev.monetdb.org/downloads/testing.
--
Sjoerd Mullender
Hi,
I am running MonetDB Database Server Toolkit v1.1 (Feb2013-SP6) ,
I have a table DailyData defined as follows.
create table DailyData (
sym varchar(32),
businessdate date,
closePrice float,
adjustedClosePrice float,
openingPrice float,
accVol float,
unique(businessdate, sym)
);
I make the following query.
with dd as (select * from DailyData where businessdate > '2013-06-01'),
r as (select t.businessdate, t.sym, 1 - t.adjustedcloseprice /
y.adjustedcloseprice as ret from dd t
left outer join dd y on t.businessdate = y.businessdate + (interval '1'
day) and t.sym = y.sym),
v as (select sym, stddev_samp(ret) as volatility from r group by sym)
select * from v where v.sym like '%.L' limit 100;
It results in a segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f5f17023700 (LWP 25178)]
0x0000003ee9327a9a in __strcmp_sse42 () from /lib64/libc.so.6
(gdb) where
#0 0x0000003ee9327a9a in __strcmp_sse42 () from /lib64/libc.so.6
#1 0x00007f6f2d4ef6f8 in rel_use_index (changes=<value optimized out>,
sql=0x7f5f08005470, rel=0x7f5f0850aa70) at rel_optimizer.c:4829
#2 0x00007f6f2d4ea225 in rewrite (sql=0x7f5f08005470, rel=0x7f5f0850aa70,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6106
#3 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f0850cb40,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#4 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f0850ec30,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#5 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f0850ef50,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#6 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f08512a90,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#7 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f0850feb0,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#8 0x00007f6f2d4ea2bc in rewrite (sql=0x7f5f08005470, rel=0x7f5f085101c0,
rewriter=0x7f6f2d4ef610 <rel_use_index>, has_changes=0x7f5f17022cac) at
rel_optimizer.c:6093
#9 0x00007f6f2d4ecf58 in _rel_optimizer (sql=0x7f5f08005470, rel=<value
optimized out>, level=0) at rel_optimizer.c:6278
#10 0x00007f6f2d484369 in sql_symbol2relation (c=0x7f5f08005470, sym=<value
optimized out>) at sql.mx:1755
#11 0x00007f6f2d454b2f in SQLparser (c=0x7f6f2df49308) at
sql_scenario.c:1708
#12 0x00007f6f352ecdd3 in runPhase (c=0x7f6f2df49308) at mal_scenario.c:522
#13 runScenarioBody (c=0x7f6f2df49308) at mal_scenario.c:558
#14 0x00007f6f352ecf1f in runScenario (c=0x7f6f2df49308) at
mal_scenario.c:586
#15 0x00007f6f352ed778 in MSserveClient (dummy=0x7f6f2df49308) at
mal_session.c:446
#16 0x0000003ee9a07851 in start_thread () from /lib64/libpthread.so.0
#17 0x0000003ee92e890d in clone () from /lib64/libc.so.6
Apparently at rel_optimizer.c:4829 strcmp(exp_relname(nre) returns NULL
which is not checked.
If I rewrite the query in the following way it works if not very fast.
with r as (select t.businessdate, t.sym, 1 - t.adjustedcloseprice /
y.adjustedcloseprice as ret from DailyData t
left outer join DailyData y on t.businessdate = y.businessdate + (interval
'1' day) and t.sym = y.sym
where t.businessdate > '2013-06-01'),
v as (select sym, stddev_samp(ret) as volatility from r group by sym)
select * from v where v.sym like '%.L' limit 100;
Regards,
Alex Shestakov.
Hello,
I am making the following adjustment to the user defined function template files .
I am using MonetDB-11.15.15 built from source on Ubuntu 12.04.
I have added to the following files in the ./sql/backends/monet5/UDF directory as shown:
80_udf.sql
create function sumProb(prob1 double, prob2 double)
returns double external name udf.sumProb;
udf.mal
module udf;
command sumProb(prob1:dbl,prob2:dbl):dbl
address UDFSumProb
comment "sum two probabilities";
udf.c
str UDFSumProb(dbl * res, dbl * prob1, dbl * prob2)
{
*res = *prob1 + *prob2;
return MAL_SUCCEED;
}
udf.h
udf_export str UDFSumProb(dbl * res, dbl * prob1, dbl * prob2);
I did a configure/make/make install and tried the following call in mclient:
declare a, b,c double; set a= 0.1; set b= 0.2; select c=jsdistance(a,b);
and get the error:
TypeException:user.s2_1[8]:'udf.sumprob' undefined in: _12:any := udf.sumprob(_8:dbl, _11:dbl)
program contains errors
Hello,
I use MonetDB in Ubuntu. When I create a table with FLOAT type, MonetDB created it as DOUBLE type.
Why does MonetDB decide to change FLOAT to DOUBLE?
How can I fix this?
Hi,
I have a segmentation fault when running an SQL query against a specific table.
I can execute queries like
"select count(*) from <TABLE>"
but the server crashes when I do
"select * from <TABLE> where businessdate = '2013-12-18' limit 100".
MonetDB version:
MonetDB Database Server Toolkit v1.1 (Feb2013-SP5)
Stack trace:
#0 0x00007f7cf2987eb1 in GDKfilepath (path=0x7f6e44f0db5d "", dir=0x7f7ceb4c51d4 "bat", name=0x0, ext=0x0) at gdk_storage.c:51
#1 0x00007f7ceb3fbbd3 in BATlocation (fnme=0x7f6e44f0fbe0, bid=<value optimized out>) at sql_optimizer.c:77
#2 0x00007f7ceb3fc59a in SQLgetStatistics (c=0x7f7cebed6308) at sql_optimizer.c:160
#3 addQueryToCache (c=0x7f7cebed6308) at sql_optimizer.c:295
#4 0x00007f7ceb3fb7ed in backend_dumpproc (be=0x7f6e3809d5f0, c=0x7f7cebed6308, cq=0x7f6e383d4090, s=0x7f6e3837bd20) at sql_gencode.c:2431
#5 0x00007f7ceb3e2067 in SQLparser (c=0x7f7cebed6308) at sql_scenario.c:1755
#6 0x00007f7cf2f35b63 in runPhase (c=0x7f7cebed6308) at mal_scenario.c:522
#7 runScenarioBody (c=0x7f7cebed6308) at mal_scenario.c:558
#8 0x00007f7cf2f35caf in runScenario (c=0x7f7cebed6308) at mal_scenario.c:586
#9 0x00007f7cf2f36508 in MSserveClient (dummy=0x7f7cebed6308) at mal_session.c:446
#10 0x0000003ee9a07851 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003ee92e890d in clone () from /lib64/libc.so.6
The problem is that it tries to de-reference null pointer 'name'.
The pointer is calculated in BATLocation as (b->T->heap.filename ? b->T->heap.filename: b->H->heap.filename).
The column in question has type real so as far as I understand there is no heap file for it.
I don't know if heap.filename should contain NULL or something else.
Regards,
Alex Shestakov.
________________________________
This email and any files transmitted with it contain confidential and proprietary information and is solely for the use of the intended recipient. If you are not the intended recipient please return the email to the sender and delete it from your computer and you must not use, disclose, distribute, copy, print or rely on this email or its contents. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. Any comments or statements made herein do not necessarily reflect those of GSA Capital. GSA Capital Partners LLP is authorised and regulated by the Financial Conduct Authority and is registered in England and Wales at Stratton House, 5 Stratton Street, London W1J 8LA, number OC309261. GSA Capital Services Limited is registered in England and Wales at the same address, number 5320529.