Hi,
I have checked out the july branch.
I do bootstrap - > configure -> make
make throws following error:
cc1: warnings being treated as errors
inet.c: In function ‘INET_comp_CW’:
inet.c:323: error: not protecting function: no buffer at least 8 bytes long
inet.c: In function ‘INETbroadcast’:
inet.c:423: error: not protecting function: no buffer at least 8 bytes long
inet.c: In function ‘INETnetmask’:
inet.c:523: error: not protecting function: no buffer at least 8 bytes long
inet.c: In function ‘INETnetwork’:
inet.c:593: error: not protecting function: no buffer at least 8 bytes long
inet.c: In function ‘INETabbrev’:
inet.c:660: error: not protecting function: no buffer at least 8 bytes long
make[7]: * [libatoms_la-inet.lo] Error 1
HELP!!!
I am using the following hack as of now: Is it a good idea to go to the given locations and change the 4 -size arrays to 8-size.?
Regards,
Tapomay
Hi,
I have a question, i need comparison the execution query times between
MonetDB and SQL 2008 in Data Warehouse (applying a different orientations
database systems). But i have a problem, i used the AdventureWorkR2 2008 but
i don't know how i can migrate the information to MonetDB.
To compare the same data.
Someone help me? Please. It's very important.
Thanks,
Raquel
--
View this message in context: http://old.nabble.com/Migration-DW-to-MonetDB-tp34348185p34348185.html
Sent from the monetdb-developers mailing list archive at Nabble.com.
Hi MonetDB People,
We currently want to manage (create, start, release, etc) MonetDB
databases from Python. What do you people think if I make a (thin)
wrapper around the 'monetdb' command as a python module (monetdb.manage)
and commit this to default?
greetings,
--
Gijs Molenaar
http://www.astro.uva.nl/people/gijs-molenaar/
SuSE Linux Enterprise Server 11 SP2, release in March. As already
covered on the bug-tracker etc. old bison won't work, so I had to
install latest version, 2.6.2 to build.
After that:
make[5]: Entering directory `/opt/MonetDB/MonetDB-11.11.5/sql/server'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../.. -I. -I../include -I./../include -I../common -I./../common
-I../storage -I./../storage -I../../clients/mapilib
-I./../../clients/mapilib -I../../common/options
-I./../../common/options -I../../common/stream -I./../../common/stream
-I../../gdk -I./../../gdk -DLIBSQLSERVER -g -O2 -c -o
libsqlserver_la-sql_scan.lo `test -f 'sql_scan.c' || echo './'`sql_scan.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I. -I../include
-I./../include -I../common -I./../common -I../storage -I./../storage
-I../../clients/mapilib -I./../../clients/mapilib -I../../common/options
-I./../../common/options -I../../common/stream -I./../../common/stream
-I../../gdk -I./../../gdk -DLIBSQLSERVER -g -O2 -c sql_scan.c -fPIC
-DPIC -o .libs/libsqlserver_la-sql_scan.o
In file included from sql_semantic.h:27,
from sql_scan.c:29:
sql_parser.h:191: error: conflicting types for 'sqlparse'
y.tab.h:678: error: previous declaration of 'sqlparse' was here
No idea how to properly fix that, but added "#define YYPARSE_PARAM parm"
at the front of sql_scan.c, which forces the prototype to retain the
parameter.
Next problem, HowToStart.rst states: "Then in any directory (preferably
a *new, empty* directory and *not* in the ``MonetDB`` top-level
directory) give the command:: .../configure [<options>]", which is
indeed recommended practice.
Unfortunately, nobody has apparently ever done this. If configure and
make are ran in a different directory from the source root, "make check"
will fail to find monetdb5/modules/mal/mal_init.mal and who knows what
else, giving long time of head-scratching.
After re-doing configure and make in the prohibited directory, make
check will report:
.
opt_sql_append : Crashed!
* (opt_sql_append.test.out.FILTERED) significantly
* (opt_sql_append.test.err.FILTERED) significantly
.......................................................................................................................................................................................................................................
* (recycle04.test.out.FILTERED) significantly
...........................................................................................................................................................................................................................................................................
!ERROR: Testing FAILED SIGNIFICANTLY (2 out of 499 tests failed)
1 out of 499 tests resulted in a crash
extras/mal_optimizer_template/opt_sql_append
1 out of 499 tests produced SIGNIFICANTLY different output
mal/recycle04
To be frank, that sounds "significantly" like something translated by
Google translator to/from some lesser known language. No idea what it's
trying to tell me, or how to proceed from there. Can't find any Google
search hits on the problems either. Suggestions?
-Jukka Santala
The MonetDB team at CWI/MonetDB BV is pleased to announce the
Jul2012-SP1 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 2012-SP1 bugfix release
Java Module * Fixed adaptive cache size used when retrieving
results, not to cause divide by zero errors when
memory gets short, bug #3119.
Client Package * mclient no longer prints the SQLSTATE at the start of
each error returned by the SQL-server.
MonetDB5 Server * The server now distinguishes between starting and
started states, such that monetdbd can wait for it to
finish starting.
Merovingian * Starting a server now waits for as long as the server
needs to possibly recover, bug #3134. In case of a
long wait, the monetdbd logfile gives extra
information on what the server is doing to recover.
* Fixed a crash of monetdbd when local databases were
unshared, bug #3135
* Resolved a problem where automatic starting of a
database initiated by multiple clients at the same
time could cause failed starts. Bug #3107
Bug Fixes * 3075: inconsistent declaration of algebra.markH with 3
input arguments
* 3090: crashed if using single identifier for where
condition
* 3093: sql fail if use scalar subquery with alias
* 3107: concurrent connections to the same stopped
database yield in multiple mserver5 starts by monetdbd
* 3119: MonetConnection$ResultSetResponse throws
java.lang.ArithmeticException: divide by zero
* 3132: test/BugTracker-2011/func_iter_vs_bulk.Bug-2826
fails
* 3134: Database gets killed by timeout during startup
* 3135: monetdbd crash while creating & loading database
;-)
Dank je wel! --- Niet alleen voor deze, maar met naam ook voor de hele
nieuwe group-by code en al die andere nieuwe schone code!!!
Stefan
On Tue, Aug 21, 2012 at 12:43:42PM +0200, Sjoerd Mullender wrote:
> Changeset: 6f001c03cd8d for MonetDB
> URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=6f001c03cd8d
> Modified Files:
> gdk/gdk_group.c
> Branch: default
> Log Message:
>
> Implemented another trivial case for grouping: all equal values.
>
>
> diffs (122 lines):
>
> diff --git a/gdk/gdk_group.c b/gdk/gdk_group.c
> --- a/gdk/gdk_group.c
> +++ b/gdk/gdk_group.c
> @@ -44,11 +44,14 @@
> * is always created. In other words, the groups argument may not be
> * NULL, but the extents and histo arguments may be NULL.
> *
> - * There are five different implementations of the grouping code.
> + * There are six different implementations of the grouping code.
> *
> * If it can be trivially determined that all groups are singletons,
> * we can produce the outputs trivially.
> *
> + * If all values in b are known to be equal (both sorted and reverse
> + * sorted), we produce a single group or copy the input group.
> + *
> * If the input bats b and g are sorted, or if the subsorted flag is
> * set (only used by BATsubsort), we only need to compare consecutive
> * values.
> @@ -102,6 +105,7 @@ BATgroup_internal(BAT **groups, BAT **ex
>
> if (b->tkey || BATcount(b) <= 1 || (g && (g->tkey || BATtdense(g)))) {
> /* grouping is trivial: 1 element per group */
> + ALGODEBUG fprintf(stderr, "#BATgroup: trivial case: 1 element per group\n");
> if (BATcount(b) == 1 && b->htype == TYPE_oid)
> ngrp = * (oid *) Hloc(b, BUNfirst(b));
> else
> @@ -132,6 +136,62 @@ BATgroup_internal(BAT **groups, BAT **ex
> }
> return GDK_SUCCEED;
> }
> + if (b->tsorted && b->trevsorted) {
> + /* all values are equal */
> + if (g == NULL) {
> + /* there's only a single group: 0 */
> + ALGODEBUG fprintf(stderr, "#BATgroup: trivial case: single output group\n");
> + ngrp = 0;
> + gn = BATconstant(TYPE_oid, &ngrp, BATcount(b));
> + if (gn == NULL)
> + goto error;
> + BATseqbase(gn, b->hseqbase);
> + *groups = gn;
> + if (extents) {
> + ngrp = gn->hseqbase;
> + en = BATconstant(TYPE_void, &ngrp, 1);
> + if (en == NULL)
> + goto error;
> + BATseqbase(BATmirror(en), ngrp);
> + *extents = en;
> + }
> + if (histo) {
> + wrd cnt = (wrd) BATcount(b);
> +
> + hn = BATconstant(TYPE_wrd, &cnt, 1);
> + if (hn == NULL)
> + goto error;
> + *histo = hn;
> + }
> + return GDK_SUCCEED;
> + }
> + if ((extents == NULL) == (e == NULL) &&
> + (histo == NULL) == (h == NULL)) {
> + /* inherit given grouping; note that if
> + * extents/histo is to be returned, we need
> + * e/h available in order to copy them,
> + * otherwise we will need to calculate them
> + * which we will do using the "normal" case */
> + ALGODEBUG fprintf(stderr, "#BATgroup: trivial case: copy input groups\n");
> + gn = BATcopy(g, g->htype, g->ttype, 0);
> + if (gn == NULL)
> + goto error;
> + *groups = gn;
> + if (extents) {
> + en = BATcopy(e, e->htype, e->ttype, 0);
> + if (en == NULL)
> + goto error;
> + *extents = en;
> + }
> + if (histo) {
> + hn = BATcopy(h, h->htype, h->ttype, 0);
> + if (hn == NULL)
> + goto error;
> + *histo = hn;
> + }
> + return GDK_SUCCEED;
> + }
> + }
> assert(g == NULL || !BATtdense(g)); /* i.e. g->ttype == TYPE_oid */
> bi = bat_iterator(b);
> cmp = BATatoms[b->ttype].atomCmp;
> @@ -167,6 +227,7 @@ BATgroup_internal(BAT **groups, BAT **ex
> (g == NULL || g->tsorted || g->trevsorted)) ||
> subsorted) {
> /* we only need to compare each entry with the previous */
> + ALGODEBUG fprintf(stderr, "#BATgroup: compare consecutive values\n");
> if (grps)
> prev = *grps++;
> pv = BUNtail(bi, BUNfirst(b));
> @@ -220,6 +281,7 @@ BATgroup_internal(BAT **groups, BAT **ex
> /* for each value, we need to scan all previous equal
> * values (a consecutive, possibly empty, range) to
> * see if we can find one in the same old group */
> + ALGODEBUG fprintf(stderr, "#BATgroup: subscan old groups\n");
> pv = BUNtail(bi, BUNfirst(b));
> ngrps[0] = ngrp;
> if (extents)
> @@ -284,6 +346,7 @@ BATgroup_internal(BAT **groups, BAT **ex
> }
> } else if (b->T->hash) {
> /* we already have a hash table on b */
> + ALGODEBUG fprintf(stderr, "#BATgroup: use existing hash table\n");
> hs = b->T->hash;
> for (r = BUNfirst(b), p = r, q = r + BATcount(b); p < q; p++) {
> v = BUNtail(bi, p);
> @@ -343,6 +406,7 @@ BATgroup_internal(BAT **groups, BAT **ex
> * build an incomplete hash table on the fly--also see
> * BATassertHeadProps and BATderiveHeadProps for
> * similar code */
> + ALGODEBUG fprintf(stderr, "#BATgroup: create partial hash table\n");
> nme = BBP_physical(b->batCacheid);
> nmelen = strlen(nme);
> if ((hp = GDKzalloc(sizeof(Heap))) == NULL ||
> _______________________________________________
> Checkin-list mailing list
> Checkin-list(a)monetdb.org
> http://mail.monetdb.org/mailman/listinfo/checkin-list
>
--
| Stefan.Manegold @ CWI.nl | DB Architectures (INS1) |
| http://CWI.nl/~manegold/ | Science Park 123 (L321) |
| Tel.: +31 (0)20 592-4212 | 1098 XG Amsterdam (NL) |
I have created a new stable branch for the next feature release. This
branch was created in order to stabilize the code before the feature
release.
From now on *only* bug fixes may go to this new stable branch. I
reserve the right to undo any changes that do not comply with this
rule. I also reserve the right to admit changes that are not strictly
bug fixes.
The name for the branch is Oct2012. So in each of your stable
checkout directories you can do
hg pull
hg update -rOct2012
to update to this new branch.
--
Sjoerd Mullender