Is this a known issue that you are working on? If so please give me the bug id where I would know when its fixed.
The case is as follows:
I have a table with 32 columns with unique key on 3 of them.
I am running live ETLs for putting data into monetdb. These ETLs are generating sql insert scripts.(inserts/updates/ddls)
Using JDBC and c3p0 connection pooling.
Have developed an external wrapper module to achieve master-master replication.
One common consistency check would be a count*.
Observation:
Queries are run in batches of 100 inserts clubbed into a single insert.
I do a select count(*) after each batch of 100.
After running 9100 queries the count* on one DB was 9100 but in the other was 9200.
The second DB had 100 records that were duplicates of 8901-9000.
It means when I inserted 9001 to 9100 the previous batch went into the store again with it and somehow surpassed the unique key constraint check.
I have also observed another case where count(*) gave less results than actual no. of rows in the DB.
REQUEST:
Just want to confirm if such kind of issues are part of active development.
Otherwise it would be really difficult for me to push monetdb usage into production.
Will try again with MonetDataSource instead of c3p0. But I doubt if the issues are client side or connection-related.
Plz note that the keys for which this occurs is random and thus I concluded it's not a data issue.
Regards,
Tapomay Dey.
Software Design Engg.
Sokrati Inc.
Email: tapomayATsokratiDOTcom
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
does anybody know if fastbit integration into scidb was ever completed?
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
Is this a known issue that you are working on? If so please give me the bug id where I would know when its fixed.
The case is as follows:
I have a table with 32 columns.
It has a unique key on 3 of them.
I know that it's recommended that you do bulk inserts from csv for performance. But in my case I am running live ETLs for putting data into monetdb. These ETLs are generating sql insert scripts.(inserts/updates/ddls)
I use JDBC and c3p0 connection pooling for executing these sqls.
I have a failover mechanism where the scripts are executed on multiple DBs and I try to keep their states consistent.
One common consistency check would be a count*.
I am running the latest stable installation from repo on Ubuntu 10.04 64 bit.
Observation:
After running 9100 queries the count* on one DB was 9100 but in the other was 9200.
I have diagnostics in place to do a select count* after running a batch of 100 queries in a single JDBC transaction.
I observed that the count* was consistent until 9000 queries were executed. It failed at 9100.
I did a manual check to see if duplicate records exist with same unique key values and they did.
Following is the query I used for the same:
select ad_group_id, count(*) from ad_groups group by ad_group_id having count(ad_group_id)>1 and client_id=X and account_id=Y;
My constraint is as follows: CONSTRAINT "ad_groups_client_id_account_id_ad_group_id_unique" UNIQUE ("client_id", "account_id", "ad_group_id")
I found exactly 100 tuples with group_by_count* = 2 and the ad_group_id(unique key) values for these exactly matched queries 8901 to 9000.
It means when I inserted 9001 to 9100 the previous batch went into the store again with it and somehow surpassed the unique key constraint check.
Please note that I am converting a batch of 100 insert queries into a single insert query and running this single bulk insert in a single JDBC transaction to reduce network traffic.
This same issue recurred at 21500 only this time it happened for 300 records with same unique key value being duplicated.
And their unique key values were exactly matching the ones in the last 3 batches
Ad_group_id s 21103-21202, 21203-21302, 21303-21402 existed twice. 21403-21502 existed exactly once.
REQUEST:
Can anyone tell me if I can enable query logs - something like what mysql has.
I will try re-installing monetdb and see if this problem goes away. :)
Merry Christmas and Warm Regards,
Tapomay
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
The MonetDB team at CWI/MonetDB BV is pleased to announce the
Oct2012-SP2 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/>.
Oct 2012-SP2 bugfix release
SQL * Fixed crash when performing an INSERT on a table with
string-like column defaulting to NULL and omitting that
column from VALUES, bug #3168
Java Module * Implemented type map support of Connection to allow custom
mapping of UDTs to Java classes. By default the INET and
URL UDTs are now mapped to
nl.cwi.monetdb.jdbc.types.{INET,URL}. Most notably,
ResultSet.getObject() and PreparedStatement.setObject()
deal with the type map.
* Fixed a problem in PreparedStatement where the prepared
statement's ResultSetMetaData (on its columns to be
produced) incorrectly threw exceptions about non existing
columns. Bug #3192
Bug Fixes * 2291: small doubles end up as NULL after arithmetic
* 2579: SQL: incorrect cast from double to int
* 2659: tuples INTERSECT vs count (... INTERSECT ...)
differs
* 2805: row_number doesn't work in complex query
* 2886: warning: Catalog parameter '' ignored
* 2977: timestamp minus date results in program error
* 2978: now() + 1 results in illegal argument
* 2999: Up-cast from SQL drops order information?
* 3048: algebra.join undefined when using multiple
arithmetic operations in SQL where-clause
* 3124: insert into table with two foreign keys crashes
mserver5
* 3136: Memleak (in querycache?) while querying
* 3143: Type resolution error in SQL procedural code
* 3163: mserver5 crashes with large number of concurrent
clients
* 3168: crash when insert varchar/char/clob with default
NULL
* 3169: php driver uses call-time pass-by-reference
* 3173: SQL queries with limit and offset clauses are unable
to use bind parameters for either
* 3181: Join query returns zero results when there is an
index on the tables
* 3185: inconsistency between documentation and
implementation of command line options
* 3186: case evaluted to early
* 3188: Storage of client history
* 3189: Overflow in calculation
* 3190: When subtracting two columns of type "timestamp", no
results are returned
* 3191: rel_optimizer.c:5596: _rel_optimizer: Assertion `0'
failed.
* 3192: "No such column with index" error if CASE in SELECT
clause
* 3199: Inconspicuous sequence of prepare, execute, commit
and close produces error
* 3205: Inet datatype handling inconsistent between int,
cast( as inet) and string
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
Martin,
assertions are not the most suitable way to check for malloc failures.
Assertions are to *assert* facts that must hold, i.e., the would be a
logical error if they do not hold. Consequently, assertions are only
enabled during development and testing, but disabled (for among others for
performance reasons) in any production builds. If triggered, assertions
stop the entire process instantly.
Failing mallocs is a runtime exception that can occur at any time for
various reasons. The code should check for this and gracefully handle such
situations with proper exeption handling.
Having said that, in particular is the man namespace is local per
query/client, a failure in one query/client should not crash the whole
server by an assertion (during development/testing) or a segfault (in
production builds), but rather only greacefull trigger and handle an
exception for that one query/client.
Also, if namespaces are global and a malloc failure prevent the whole server
from continuing properly, it should at least (try to) gracefully shut itself
down (with a proper error message), rather than crashing instantly with an
assertion of segfault.
Best,
Stefan
On Wed, Dec 19, 2012 at 11:53:37AM +0100, Martin Kersten wrote:
> Changeset: 2a9bd075c039 for MonetDB
> URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=2a9bd075c039
> Modified Files:
> monetdb5/mal/mal_namespace.c
> Branch: Feb2013
> Log Message:
>
> Properly realloc the namespace
> The expandName always lead to a different anchoring point of the namespace.
> This may leave concurrent threads with dead meat.
> This patch reduces the chance on a SEGfault.
>
>
> diffs (37 lines):
>
> diff --git a/monetdb5/mal/mal_namespace.c b/monetdb5/mal/mal_namespace.c
> --- a/monetdb5/mal/mal_namespace.c
> +++ b/monetdb5/mal/mal_namespace.c
> @@ -66,26 +66,13 @@ typedef struct NAMESPACE{
> static Namespace namespace;
>
> static void expandNamespace(void){
> - str *nme;
> - size_t *length;
> - int *link, newsize, incr = 2048;
> -
> - newsize= namespace.size + incr;
> - nme= (str *) GDKmalloc(sizeof(str *) * newsize);
> - assert(nme != NULL); /* we cannot continue */
> - link= (int *) GDKmalloc(sizeof(int) * newsize);
> - assert(link != NULL); /* we cannot continue */
> - length = (size_t *) GDKmalloc(sizeof(size_t) * newsize);
> - assert(length != NULL); /* we cannot continue */
> -
> - memcpy(nme, namespace.nme, sizeof(str *) * namespace.nmetop);
> - memcpy(link, namespace.link, sizeof(int) * namespace.nmetop);
> - memcpy(length, namespace.length, sizeof(size_t) * namespace.nmetop);
> -
> - namespace.size += incr;
> - GDKfree(namespace.nme); namespace.nme= nme;
> - GDKfree(namespace.link); namespace.link= link;
> - GDKfree(namespace.length); namespace.length= length;
> + namespace.size += 2048;
> + namespace.nme= (str *) GDKrealloc(namespace.nme, sizeof(str *) * namespace.size);
> + assert(namespace.nme != NULL); /* we cannot continue */
> + namespace.link= (int *) GDKrealloc(namespace.link, sizeof(int) * namespace.size);
> + assert(namespace.link != NULL); /* we cannot continue */
> + namespace.length = (size_t *) GDKrealloc(namespace.length, sizeof(size_t) * namespace.size);
> + assert(namespace.length != NULL); /* we cannot continue */
> }
>
> void initNamespace(void) {
> _______________________________________________
> 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) |
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list
On 2012-12-14 12:10, Gijs Molenaar wrote:
> Changeset: 81f191d61822 for MonetDB
> URL: http://dev.monetdb.org/hg/MonetDB?cmd=changeset;node=81f191d61822
> Modified Files:
> clients/python2/monetdb/mapi.py
> clients/python3/monetdb/mapi.py
> Branch: default
> Log Message:
>
> fixed a low level bug where empty mapi results where not properly handled
Is this is fix that should have gone to the Oct2012 branch?
Please, make sure you fix bugs in the lowest branch where the bug occurs
and that is still maintained. Currently the still maintained branches
are Oct2012, Feb2013 and default.
>
> diffs (30 lines):
>
> diff --git a/clients/python2/monetdb/mapi.py b/clients/python2/monetdb/mapi.py
> --- a/clients/python2/monetdb/mapi.py
> +++ b/clients/python2/monetdb/mapi.py
> @@ -163,9 +163,9 @@ class Connection(object):
> self.__putblock(operation)
> response = self.__getblock()
> if not len(response):
> - return True
> + return ""
> elif response.startswith(MSG_OK):
> - return response[3:].strip() or True
> + return response[3:].strip() or ""
Isn't this equivalent to:
return response[3:].strip()
> if response == MSG_MORE:
> # tell server it isn't going to get more
> return self.cmd("")
> diff --git a/clients/python3/monetdb/mapi.py b/clients/python3/monetdb/mapi.py
> --- a/clients/python3/monetdb/mapi.py
> +++ b/clients/python3/monetdb/mapi.py
> @@ -163,9 +163,9 @@ class Connection(object):
> self.__putblock(operation)
> response = self.__getblock()
> if not len(response):
> - return True
> + return ""
> elif response.startswith(MSG_OK):
> - return response[3:].strip() or True
> + return response[3:].strip() or ""
> if response == MSG_MORE:
> # tell server it isn't going to get more
> return self.cmd("")
> _______________________________________________
> checkin-list mailing list
> checkin-list(a)monetdb.org
> http://mail.monetdb.org/mailman/listinfo/checkin-list
>
--
Sjoerd Mullender
_______________________________________________
developers-list mailing list
developers-list(a)monetdb.org
http://mail.monetdb.org/mailman/listinfo/developers-list