Hello developers,
I found a bug when using BigDecimals in prepared statements with MonetDB¹s
JDBC driver.
If I have a column of type DECIMAL(15,2) and insert a big decimal with the
value 627000.00 through a PreparedStatement, it will turn out as 630000.00
in the DB, since the MonetDB JDBC driver currently mixes up "precision"
and "scale", and rounds 627000.00 to a precision of 2 ciphers.
I made a bugfix for it, and it can be seen here:
https://github.com/shaagerup/monet-jdbc/commit/
ebc5e654dc28e3b56d4c4b610d3d339e675d6c2c
I¹m sorry for not committing it directly to your repository, but since I
am not a Mercurial user, I hope someone else will use this information to
improve the official JDBC driver.
Best regards
Søren Haagerup
I tryied MonetDB-11.21.5 with below sql on two table. ods_ply_base has 50,000,000 rows of record, ods_agent has 100,000 rows of recored.c_cmpny_agt_cde and c_cha_cde are text column.But mserver5 exit with SIGSEGV signal.Below is the stack show by gdb.sql>select * from ods_ply_base left join (select * from ods_agent where business_end_date > now()) as bb on c_cmpny_agt_cde=bb.c_cha_cde;81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.12.2-15.el7_1.x86_64 libcom_err-1.42.9-7.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 libxml2-2.9.1-5.el7_1.2.x86_64 ncurses-libs-5.9-13.20130511.el7.x86_64 openssl-libs-1.0.1e-42.el7.9.x86_64 pcre-8.32-14.el7.x86_64 readline-6.2-9.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64(gdb) cContinuing.[New Thread 0x7f4603dfe700 (LWP 20663)]Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x7f46353e9700 (LWP 20592)]incref (lock=<optimized out>, logical=<optimized out>, i=1567) at gdk_bbp.c:21562156 hp = bs->B.H->heap.parentid;(gdb)(gdb) bt#0 incref (lock=<optimized out>, logical=<optimized out>, i=1567) at gdk_bbp.c:2156#1 BBPincref (i=i@entry=1567, logical=logical@entry=0) at gdk_bbp.c:2221#2 0x00007f46477252a8 in BATdescriptor (i=1567) at ../../../gdk/gdk.h:2599#3 do_join (r1=0x7f37bc354d30, r2=0x7f37bc354d50, rid=<optimized out>, r2id=r2id@entry=0x0, slid=0x7f37bc207490, srid=0x7f37bc207490, op=op@entry=0, c1=c1@entry=0x0, c2=c2@entry=0x0, li=li@entry=0, hi=hi@entry=0, nil_matches=nil_matches@entry=0x7f37bc2074b0 "", estimate=estimate@entry=0x7f37bc2074d0, joinfunc=0x7f464734cb20 <BATsubjoin>, thetafunc=thetafunc@entry=0x0, bandfunc=bandfunc@entry=0x0, rangefunc=rangefunc@entry=0x0, funcname=funcname@entry=0x7f46477db3ef "algebra.subjoin", lid=<optimized out>) at algebra.c:614#4 0x00007f464772808c in ALGsubjoin (r1=<optimized out>, r2=<optimized out>, lid=<optimized out>, rid=<optimized out>, slid=<optimized out>, srid=<optimized out>, nil_matches=0x7f37bc2074b0 "", estimate=0x7f37bc2074d0) at algebra.c:681#5 0x00007f46476d6b84 in malCommandCall (stk=stk@entry=0x7f37bc207020, pci=pci@entry=0x7f46315dd260) at mal_interpreter.c:119#6 0x00007f46476d815b in runMALsequence (cntxt=<optimized out>, mb=<optimized out>, startpc=<optimized out>, stoppc=<optimized out>, stk=<optimized out>, env=env@entry=0x0, pcicaller=pcicaller@entry=0x0) at mal_interpreter.c:655#7 0x00007f46476d9d0e in DFLOWworker (T=<optimized out>) at mal_dataflow.c:376#8 0x00007f4645481df5 in start_thread (arg=0x7f46353e9700) at pthread_create.c:308#9 0x00007f46451af1ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113Is this bug of monetdb?zorpior
Hey guys,
A boolean type column seems to fit in a byte, I guess the extra space is to represent nulls (since it ain't a qubit). But does that mean that no column type is actually ':bit'?
Given a BAT, how to distinguish between a byte (tinyint) column and a boolean one?
Thanks,
Dimitar
Hi,
I read the following lines in a thesis on MonetDB titled - "Improving
Transactional Stability in MonetDB" where in they had explained the
concurrency control in MonetDB as
"Concurrent updates (writers) are not anticipated and in case of N
conicting transactions, only one of them (the one having the earliest
time-stamp) is guaranteed to eventually commit its changes.
Concurrent appends (on the same table) are detected as write-to-write
conflicts and only the writer carrying the earliest time-stamp will end up
committing successfully, the rest will be aborted."
Why is that the transaction having the earliest timestamp is allowed to
commit, in case of a conflict?
Shouldn't it be the latest transaction that should commit on a data, since
the latest transaction would be having the latest version of data?
Or, what am I getting wrong here? Any help much appreciated.
Thanks & Regards,
Vijayakrishna.P.
Mobile : (+91) 9500402305.
Hello, i'm working on a grails plugin to easily integrate with monetDB.
So I would like to here what functionalities will be useful to you guys
because I want it to be useful to all of you to.
I'm implementing it from the monet jar 2.17 and I hope to have it up in
grails plugins as soon as possible. Btw any collaboration will be really
welcome
Regards