Dear Monet Team,
We're having an issue in which certain data is causing mserver5 to crash.
After this condition is hit, mserver5 crashes at every startup and always
dumps an identical core.
We're running Monet 11.13.7 on Ubuntu Linux 64 bit.
The error is happening on line 1142 of gdk_atoms.c:
if (GDK_STRCMP(v, (str) (next + 1) + extralen) == 0) {
Examining the core dump revealed that (next + 1) + extralen is referring to
an out of bounds address. Here's the backtrace:
#0 0x00007faf58414829 in strPut (h=0x1e2d180, dst=0x7fff592cf8f8,
v=0x314dac0 "SAD014H1") at gdk_atoms.c:1142
#1 0x00007faf582dc935 in BATappend (b=0x1e2cf90, n=0x32dfdb0, force=1
'\001') at gdk_batop.c:578
#2 0x00007faf584c301e in la_bat_updates (lg=0x2d9b030, la=0x2c3ef48) at
gdk_logger.c:429
#3 0x00007faf584c3cf9 in la_apply (lg=0x2d9b030, c=0x2c3ef48) at
gdk_logger.c:645
#4 0x00007faf584c3f26 in tr_commit (lg=0x2d9b030, tr=0x2e247d0) at
gdk_logger.c:705
#5 0x00007faf584c4533 in logger_readlog (lg=0x2d9b030,
filename=0x7fff592d1e80
"/opt/clicksecurity/data/_monetdb/click/sql_logs/sql/log.56") at
gdk_logger.c:823
#6 0x00007faf584c482a in logger_readlogs (lg=0x2d9b030, fp=0x2d9b160,
filename=0x7fff592d3f90
"/opt/clicksecurity/data/_monetdb/click/sql_logs/sql/log") at
gdk_logger.c:896
#7 0x00007faf584c6f3e in logger_new (debug=0, fn=0x7faf500adfa8 "sql",
logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click",
version=52001, prefuncp=0x7faf500746a1 <bl_preversion>,
postfuncp=0x7faf500747ed <bl_postversion>) at gdk_logger.c:1420
#8 0x00007faf584c704e in logger_create (debug=0, fn=0x7faf500adfa8 "sql",
logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click",
version=52001, prefuncp=0x7faf500746a1 <bl_preversion>,
postfuncp=0x7faf500747ed <bl_postversion>) at gdk_logger.c:1446
#9 0x00007faf50075b19 in bl_create (logdir=0x7faf50090a08 "sql_logs",
dbname=0x1fa3da0 "click", cat_version=52001) at bat_logger.c:249
#10 0x00007faf50060ce4 in store_init (debug=0, store=store_bat,
logdir=0x7faf50090a08 "sql_logs", dbname=0x1fa3da0 "click", stk=0)
at store.c:1287
#11 0x00007faf4ffe3d3c in mvc_init (dbname=0x1fa3da0 "click", debug=0,
store=store_bat, stk=0) at sql_mvc.c:51
#12 0x00007faf4ff66874 in SQLinit () at sql_scenario.c:230
#13 0x00007faf4ff6651f in SQLprelude () at sql_scenario.c:159
#14 0x00007faf58b3085d in malCommandCall (stk=0x2d36e80, pci=0x2ea5520) at
mal_interpreter.c:137
#15 0x00007faf58b331b5 in runMALsequence (cntxt=0x7faf5988c020,
mb=0x1e04310, startpc=1, stoppc=0, stk=0x2d36e80, env=0x0, pcicaller=0x0)
at mal_interpreter.c:710
#16 0x00007faf58b323c1 in runMAL (cntxt=0x7faf5988c020, mb=0x1e04310,
startpc=1, mbcaller=0x0, env=0x0, pcicaller=0x0)
at mal_interpreter.c:454
#17 0x00007faf58b60a08 in MALengine (c=0x7faf5988c020) at mal_session.c:619
#18 0x00007faf58b5f21f in malBootstrap () at mal_session.c:64
#19 0x00007faf58b1313b in mal_init () at mal.c:244
#20 0x000000000040340e in main (argc=22, av=0x7fff592db568) at
mserver5.c:582
I'm digging into it now, but I was hoping that it might ring some bells.
Thanks,
--
Percy Wegmann
+1 512 637 8500 ext 148
Hello,
Before MonetDB Feb2013 Release, I used to start MonetDB using the
following Windows command:
MSQLserver.bat --dbname=MyNewDatabase
MSQLserver.bat called M5server.bat, M5server.bat set --dbfarm option.
The result was that database with name specified with --dbname
option was created in the directory specified with --dbfarm option.
MonetDB Feb2013 Release replaced --dbname and --dbfarm options with
single --dbpath option. This --dbpath option is set to
some_path\dbfarm\demo in M5server.bat.
So, now (MonetDB Feb2013 Release) when I start MonetDB with the
following Windows command:
MSQLserver.bat --dbpath=some_path\MyNewDatabase
MonetDB ignores my --dbpath option, because it uses --dbpath option
from M5server.bat!
So, how can I start MonetDB and create my own database?
Thank you very much,
Gennadiy
Hi, I am using a brand new mserver.exe instance of MonetDB5 on Windows. I
am getting the error: "COMMIT: transaction is aborted because of concurency
conflicts, will ROLLBACK instead" that I'm not sure I should? Shouldn't I
be able to use the COPY command on two separate CSV files into two separate
data tables at once? I don't think this behavior is correct, but maybe I'm
wrong? :/
If this is incorrect behavior, should I file a bug report for this?
The files you can use to re-create this error are:
http://downloads.cms.gov/BSAPUF/2008_BSA_PartD_Events_PUF_1.ziphttp://downloads.cms.gov/BSAPUF/2008_BSA_PartD_Events_PUF_2.zip
I create an mserver.exe instance with:
# MonetDB 5 server v11.13.9 "Oct2012-SP3"
# Serving database 'bsapuf', using 8 threads
# Compiled for x86_64-pc-winnt/64bit with 64bit OIDs dynamically linked
# Found 7.860 GiB available main-memory.
# Copyright (c) 1993-July 2008 CWI.
# Copyright (c) August 2008-2013 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:50003/
# MonetDB/JAQL module loaded
# MonetDB/SQL module loaded
Then I ran this command in the first mclient:
CREATE TABLE bsa1 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE
PRECISION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION,
PDE_DRUG_STR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION,
PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION,
PDE_DRUG_QTY_DIS DOUBLE PRECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION,
PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION,
PDE_DRUG_TYPE_CD DOUBLE PRECISION) ;
copy 1000000 offset 2 records into bsa1 from
'c:\\temp\\2008_BSA_PartD_Events_PUF_1.csv' using delimiters ',' NULL AS
'' ;
And (at the same time) ran this command in the second mclient:
CREATE TABLE bsa2 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE
PRECISION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION,
PDE_DRUG_STR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION,
PDE_DRUG_DOSE_CD DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION,
PDE_DRUG_QTY_DIS DOUBLE PRECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION,
PDE_DRUG_COST DOUBLE PRECISION, PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION,
PDE_DRUG_TYPE_CD DOUBLE PRECISION) ;
copy 1000000 offset 2 records into bsa2 from
'c:\\temp\\2008_BSA_PartD_Events_PUF_2.csv' using delimiters ',' NULL AS
'' ;
Here were the results. One worked, one didn't:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\anthonyd.KFF>cd ..
C:\Users>cd ..
C:\>cd "Program Files\MonetDB\MonetDB5"
C:\Program Files\MonetDB\MonetDB5>mclient -p 50003 "bsapuf"
user(win32):monetdb
password:
Welcome to mclient, the MonetDB/SQL interactive terminal (Oct2012-SP3)
Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsapuf'
Type \q to quit, \? for a list of available commands
auto commit mode: on
sql>
sql>
sql>CREATE TABLE bsa2 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE
PRECI
SION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION,
PDE_DRUG_S
TR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION,
PDE_DRUG_DOSE_CD
DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS
DOUBLE P
RECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE
PRECISION,
PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ;
operation successful (9.511ms)
sql>
sql>copy 1000000 offset 2 records into bsa2 from
'c:\\temp\\2008_BSA_PartD_Event
s_PUF_2.csv' using delimiters ',' NULL AS '' ;
1000000 affected rows (42.4s)
sql>
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\anthonyd.KFF>cd ..
C:\Users>cd ..
C:\>cd "Program Files\MonetDB\MonetDB5"
C:\Program Files\MonetDB\MonetDB5>mclient -p 50003 "bsapuf"
user(win32):monetdb
password:
Welcome to mclient, the MonetDB/SQL interactive terminal (Oct2012-SP3)
Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsapuf'
Type \q to quit, \? for a list of available commands
auto commit mode: on
sql>\d
sql>CREATE TABLE bsa1 (PDE_EVENT_ID VARCHAR(255), BENE_SEX_IDENT_CD DOUBLE
PRECI
SION, BENE_AGE_CAT_CD DOUBLE PRECISION, PDE_DRUG_CD DOUBLE PRECISION,
PDE_DRUG_S
TR_CD DOUBLE PRECISION, PDE_DRUG_STR_UNITS_CD DOUBLE PRECISION,
PDE_DRUG_DOSE_CD
DOUBLE PRECISION, PDE_DRUG_CLASS_CD DOUBLE PRECISION, PDE_DRUG_QTY_DIS
DOUBLE P
RECISION, PDE_DRUG_DAY_SPLY_CD DOUBLE PRECISION, PDE_DRUG_COST DOUBLE
PRECISION,
PDE_DRUG_PAT_PAY_CD DOUBLE PRECISION, PDE_DRUG_TYPE_CD DOUBLE PRECISION) ;
operation successful (8.636ms)
sql>
sql>copy 1000000 offset 2 records into bsa1 from
'c:\\temp\\2008_BSA_PartD_Event
s_PUF_1.csv' using delimiters ',' NULL AS '' ;
1000000 affected rows (41.6s)
COMMIT: transaction is aborted because of concurency conflicts, will
ROLLBACK in
stead
sql>
sql>
Thanks as always! Anthony
The MonetDB team at CWI/MonetDB BV is pleased to announce the
Feb2013 feature 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/>.
Feb 2013 feature release
Testing Environment * enabled "top-level" Mtest.py So far, while
Mtest.py could be called in any subdirectory of
the MonetDB source tree (and could then run all
tests in the entire sub-tree), it was not possible
to call Mtest.py in the top-level MonetDB source
directory to run all tests. Instead, to run all
tests, Mtest.py had to be called at least 4 times,
once in each of these directories: "clients",
"monetdb5", "sql", "geom". Now, it is possible to
call Mtest.py once in the top-level MonetDB source
directory to run all tests in one go. The
behaviour of calling Mtest.py in any subdirectory,
including the four mentioned above, did not
changed, other than that now obsolete command line
options "-p / --package <package>" and "-5 /
--monetdb5" have been removed.
Java Module * merocontrol was changed to return server URIs, and
lastStop time. Connections and dbpath were
removed.
* Mapi protocol v8 support was removed from
MapiSocket. Protocol v8 has not been used by the
servers any more since Apr2012 release
Client Package * Mapi protocol v8 support was removed from all
client drivers. Protocol v8 has not been used by
the servers any more since Apr2012 release
* The tool mnc was removed from installations
* msqldump: Implmented an option (--table/-t) to
dump a single table.
* Changed msqdump's trace option to be in line with
mclient. In both cases, the long option is
--Xdebug and the short option is -X.
MonetDB5 Server * mserver5: The --dbname and --dbfarm options have
been replaced by the single --dbpath option.
* The scheduler of mserver5 was changed to use a
fixed set of workers to perform the work for all
connected clients. Previously, each client
connection had its own set of workers, easily
causing resource problems upon multiple
connections to the server.
Merovingian * Upgrade support for dbfarms from Mar2011 and
Aug2011 was dropped
* monetdb status now uses a more condensed output,
to cater for the uris being shown, and prints how
long a database is stopped, or how long ago it
crashed
* monetdb status now prints the connection uri for
each database, when available. The connections and
database path properties have been dropped.
* monetdb status now prints last crash date only if
the database has not been started since.
Bug Fixes * 2291: small doubles end up as NULL after
arithmetic
* 3215: Calculation Date function using interval and
year
* 3033: stethoscope needs better documentation
* 3084: Timestamp arithmetic very slow (especially
on Windows)
* 3125: Python tests fail after recent Python API
changes
* 3172: assertion fails on table function with
subselects as parameters
* 3178: one scan is enough to implement ALGstdev_@1
in monetdb5/modules/kernel/algebra.mx
* 3179: LIKE: batstr.like+algebra.uselect called
instead of pcre.like_filter
* 3193: Expressions not supported in the GROUP BY or
ORDER BY clause.
* 3216: "unknown property" error setting format and
width in .monetdb file
* 3217: gdk_posix fails to compile under NetBSD
* 3221: can no execute large statements
* 3227: MT_set_lock() call on an non-initialized
lock
Just curious, I follow the mailing lists closely very recently. Is there a way, or does it make sense for someone like me to have access to update the MonetDb documentation based on responses from the maintainers here? I would be happy to collect some of this information and send it in for review before posting as documentation.
Brandon
Sent from my iPhone
I am running MonetDB5 Oct 2012 SP3 on my work Windows 7 desktop computer.
My office has what I imagine is a pretty typical mix of networked machines,
with a few more powerful servers and larger shared drives that everyone can
connect to. (1) When I attempt to import a large CSV file into a MonetDB
server on the _local_ disk (C:\My Directory\MonetDB\dbfarm), the
importation command runs as expected. (2) When I attempt to import the
same CSV file to a MonetDB server stored on a networked drive, the import
command fails. (3) Finally, when I *remote desktop* into the server that
the networked drive is actually attached to, the importation succeeds
again! Here's the error seen in scenario (2) --
GDKerror:!ERROR: GDKunlink(bat\13\1327.tail)
!OS: The process cannot access the file because it is being used by another
process.
GDKunlink(bat\13\1327.theap)
!OS: The process cannot access the file because it is being used by another
process.
So it seems pretty clear that something about windows networked drives is
the culprit. This error does not occur on every file (larger files seem
more prone to the error), but if an import command does not work on a file,
it _consistently_ does not work on that file. As an example, importing
this large file works with methods (1) and (3) but not (2) --
http://downloads.cms.gov/BSAPUF/2008_BSA_Carrier_Line_Items_PUF_1.zip
I tried disabling the windows firewall and using different server ports,
but I still hit the above error.
I spoke with Hannes about it briefly, he said: "The issue is probably
related to the Windows mmap() implementation when talking to a SMB
filesystem. It is far from certain that there is something we can do about
this, but in either case, we'd like to know about it."
Should I submit an official bug report to http://bugs.monetdb.org/ ?
Perhaps we are overlooking something obvious about our windows network's
configuration..
Thanks!!!
Here is my MonetDB server info, followed by the COPY INTO commands run in
-X mode for each of the three scenarios:
# MonetDB 5 server v11.13.9 "Oct2012-SP3"
# Serving database 'bsa', using 2 threads
# Compiled for x86_64-pc-winnt/64bit with 64bit OIDs dynamically linked
# Found 15.873 GiB available main-memory.
# Copyright (c) 1993-July 2008 CWI.
# Copyright (c) August 2008-2013 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:50001/
# MonetDB/JAQL module loaded
# MonetDB/SQL module loaded
**************************
(1) - local disk - works -----
fetch next block: start at:196
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsa'
closing result set
Type \q to quit, \? for a list of available commands
auto commit mode: on
mapi_query:46:SET TIME ZONE INTERVAL '-05:00' HOUR TO MINUTE
fetch next block: start at:198
got next block: length:3
text:&3
got complete block:
text:&3
read_line:&3
allocating new result set
fetch next block: start at:201
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
closing result set
sql>create table mytable (
mapi_query_part:23:create table mytable (
fetch next block: start at:203
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:206
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_id VARCHAR(255),
mapi_query_part:27: car_line_id VARCHAR(255),
fetch next block: start at:208
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:211
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_sex_ident_cd INTEGER,
mapi_query_part:28: bene_sex_ident_cd INTEGER,
fetch next block: start at:213
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:216
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_age_cat_cd INTEGER,
mapi_query_part:26: bene_age_cat_cd INTEGER,
fetch next block: start at:218
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:221
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_icd9_dgns_cd VARCHAR(255),
mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255),
fetch next block: start at:223
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:226
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_hcpcs_cd VARCHAR(255),
mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255),
fetch next block: start at:228
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:231
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_betos_cd VARCHAR(255),
mapi_query_part:33: car_line_betos_cd VARCHAR(255),
fetch next block: start at:233
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:236
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_srvc_cnt INTEGER,
mapi_query_part:28: car_line_srvc_cnt INTEGER,
fetch next block: start at:238
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:241
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_prvdr_type_cd INTEGER,
mapi_query_part:33: car_line_prvdr_type_cd INTEGER,
fetch next block: start at:243
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:246
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_cms_type_srvc_cd VARCHAR(255),
mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255),
fetch next block: start at:248
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:251
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_place_of_srvc_cd INTEGER,
mapi_query_part:36: car_line_place_of_srvc_cd INTEGER,
fetch next block: start at:253
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:256
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_hcpcs_pmt_amt INTEGER
mapi_query_part:27: car_hcpcs_pmt_amt INTEGER
fetch next block: start at:258
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:261
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more>) ;
mapi_query_part:4:) ;
fetch next block: start at:263
got next block: length:3
text:&3
got complete block:
text:&3
read_line:&3
allocating new result set
fetch next block: start at:266
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
operation successful (118.294ms)
closing result set
sql>
fetch next block: start at:268
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
sql>COPY 9676440 offset 2 records INTO mytable FROM 'C:\My
Directory\BSAPUF\2008
\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL
AS '
' ;
mapi_query_part:160:COPY 9676440 offset 2 records INTO mytable FROM 'C:\My
Direc
tory\BSAPUF\2008\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS
',','\n
','\"' NULL AS '' ;
fetch next block: start at:270
got next block: length:14
text:&2 9676439 -1
got complete block:
text:&2 9676439 -1
read_line:&2 9676439 -1
allocating new result set
fetch next block: start at:284
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
9676439 affected rows (3m 26s)
closing result set
sql>
**************************
(2) - networked disk - fails -----
read_line:☺
more> car_line_id VARCHAR(255),
mapi_query_part:27: car_line_id VARCHAR(255),
fetch next block: start at:208
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:211
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_sex_ident_cd INTEGER,
mapi_query_part:28: bene_sex_ident_cd INTEGER,
fetch next block: start at:213
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:216
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_age_cat_cd INTEGER,
mapi_query_part:26: bene_age_cat_cd INTEGER,
fetch next block: start at:218
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:221
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_icd9_dgns_cd VARCHAR(255),
mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255),
fetch next block: start at:223
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:226
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_hcpcs_cd VARCHAR(255),
mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255),
fetch next block: start at:228
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:231
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_betos_cd VARCHAR(255),
mapi_query_part:33: car_line_betos_cd VARCHAR(255),
fetch next block: start at:233
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:236
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_srvc_cnt INTEGER,
mapi_query_part:28: car_line_srvc_cnt INTEGER,
fetch next block: start at:238
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:241
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_prvdr_type_cd INTEGER,
mapi_query_part:33: car_line_prvdr_type_cd INTEGER,
fetch next block: start at:243
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:246
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_cms_type_srvc_cd VARCHAR(255),
mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255),
fetch next block: start at:248
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:251
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_place_of_srvc_cd INTEGER,
mapi_query_part:36: car_line_place_of_srvc_cd INTEGER,
fetch next block: start at:253
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:256
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_hcpcs_pmt_amt INTEGER
mapi_query_part:27: car_hcpcs_pmt_amt INTEGER
fetch next block: start at:258
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:261
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more>) ;
mapi_query_part:4:) ;
fetch next block: start at:263
got next block: length:3
text:&3
got complete block:
text:&3
read_line:&3
allocating new result set
fetch next block: start at:266
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
operation successful (289.145ms)
closing result set
sql>
fetch next block: start at:268
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
sql>COPY 9676440 offset 2 records INTO mytable FROM 'C:\My
Directory\BSAPUF\2008
\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL
AS '
' ;
mapi_query_part:160:COPY 9676440 offset 2 records INTO mytable FROM 'C:\My
Direc
tory\BSAPUF\2008\2008_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS
',','\n
','\"' NULL AS '' ;
fetch next block: start at:270
got next block: length:252
text:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!GDKunlink(bat\13\1327.theap)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!
got complete block:
text:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!GDKunlink(bat\13\1327.theap)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!
read_line:!GDKerror:!ERROR: GDKunlink(bat\13\1327.tail)
allocating new result set
got complete block:
text:!!OS: The process cannot access the file because it is being used by
anothe
r process.
!GDKunlink(bat\13\1327.theap)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!
read_line:!!OS: The process cannot access the file because it is being used
by a
nother process.
got complete block:
text:!GDKunlink(bat\13\1327.theap)
!!OS: The process cannot access the file because it is being used by
another pro
cess.
!
read_line:!GDKunlink(bat\13\1327.theap)
got complete block:
text:!!OS: The process cannot access the file because it is being used by
anothe
r process.
!
read_line:!!OS: The process cannot access the file because it is being used
by a
nother process.
got complete block:
text:!
read_line:!
fetch next block: start at:522
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
GDKerror:!ERROR: GDKunlink(bat\13\1327.tail)
!OS: The process cannot access the file because it is being used by another
proc
ess.
GDKunlink(bat\13\1327.theap)
!OS: The process cannot access the file because it is being used by another
proc
ess.
closing result set
sql>
**************************
(3) - remote desktop into server so networked disk becomes local disk -
works -----
read_line:[ "monet_release", "Oct2012-SP3" ]
fetch next block: start at:196
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
Database: MonetDB v11.13.9 (Oct2012-SP3), 'bsa'
closing result set
Type \q to quit, \? for a list of available commands
auto commit mode: on
mapi_query:46:SET TIME ZONE INTERVAL '-05:00' HOUR TO MINUTE
fetch next block: start at:198
got next block: length:3
text:&3
got complete block:
text:&3
read_line:&3
allocating new result set
fetch next block: start at:201
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
closing result set
sql>create table mytable3 (
mapi_query_part:24:create table mytable3 (
fetch next block: start at:203
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:206
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_id VARCHAR(255),
mapi_query_part:27: car_line_id VARCHAR(255),
fetch next block: start at:208
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:211
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_sex_ident_cd INTEGER,
mapi_query_part:28: bene_sex_ident_cd INTEGER,
fetch next block: start at:213
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:216
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> bene_age_cat_cd INTEGER,
mapi_query_part:26: bene_age_cat_cd INTEGER,
fetch next block: start at:218
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:221
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_icd9_dgns_cd VARCHAR(255),
mapi_query_part:37: car_line_icd9_dgns_cd VARCHAR(255),
fetch next block: start at:223
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:226
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_hcpcs_cd VARCHAR(255),
mapi_query_part:33: car_line_hcpcs_cd VARCHAR(255),
fetch next block: start at:228
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:231
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_betos_cd VARCHAR(255),
mapi_query_part:33: car_line_betos_cd VARCHAR(255),
fetch next block: start at:233
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:236
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_srvc_cnt INTEGER,
mapi_query_part:28: car_line_srvc_cnt INTEGER,
fetch next block: start at:238
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:241
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_prvdr_type_cd INTEGER,
mapi_query_part:33: car_line_prvdr_type_cd INTEGER,
fetch next block: start at:243
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:246
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_cms_type_srvc_cd VARCHAR(255),
mapi_query_part:41: car_line_cms_type_srvc_cd VARCHAR(255),
fetch next block: start at:248
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:251
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_line_place_of_srvc_cd INTEGER,
mapi_query_part:36: car_line_place_of_srvc_cd INTEGER,
fetch next block: start at:253
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:256
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more> car_hcpcs_pmt_amt INTEGER
mapi_query_part:27: car_hcpcs_pmt_amt INTEGER
fetch next block: start at:258
got next block: length:3
text:☺☻
got complete block:
text:☺☻
read_line:☺☻
fetch next block: start at:261
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
more>) ;
mapi_query_part:4:) ;
fetch next block: start at:263
got next block: length:3
text:&3
got complete block:
text:&3
read_line:&3
allocating new result set
fetch next block: start at:266
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
operation successful (276.500ms)
closing result set
sql>
fetch next block: start at:268
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
sql>COPY 9676440 offset 2 records INTO mytable3 FROM
'v:\temp\2008_BSA_Carrier_L
ine_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS '' ;
mapi_query_part:141:COPY 9676440 offset 2 records INTO mytable3 FROM
'v:\temp\20
08_BSA_Carrier_Line_Items_PUF_1.csv' USING DELIMITERS ',','\n','\"' NULL AS
'' ;
fetch next block: start at:270
got next block: length:14
text:&2 9676439 -1
got complete block:
text:&2 9676439 -1
read_line:&2 9676439 -1
allocating new result set
fetch next block: start at:284
got next block: length:0
text:
got complete block:
text:☺
read_line:☺
9676439 affected rows (2m 14s)
closing result set
sql>
Hi,
I intend to run TPCH benchmark on MonetDB. I have executed one iteration of benchmark through run.all script provided under sql/benchmarks/tpch. Please may I know if there is a script or framework available to run tpch benchmark for 'X' duration and get throughput and latency numbers for each query?
Second, I want to generated data with big scale factor. I searched monetdb mailing list and found out that DBGEN should be used for that. As there is no specific DBGEN provided by monetdb so I have downloaded from http://www.tpc.org/tpch/ . But please let me know which of the following database shall I select while building DBGEN. Official DBGEN supports the following database options:
INFORMIX, DB2, TDAT (Teradata), SQLSERVER, SYBASE, ORACLE, VECTORWISE
Thanks for the help
Kind Regards, Ahmad
My questions are simple:
what causes crashes?
what is health?
how do we stop health from degrading?
Following is the status of my db-
msearch_stats_db:
database name: msearch_stats_db
state: running
locked: no
scenarios: mal sql msql
start count: 140
stop count: 1
crash count: 138
current uptime: 1m 49s
average uptime: 15m 33s
maximum uptime: 15m 33s
minimum uptime: 15m 33s
last start with crash: 2013-02-10 17:32:36
last start: 2013-02-10 17:32:47
last stop: 2013-02-06 11:27:15
average of crashes in the last start attempt: 0
average of crashes in the last 10 start attempts: 0.90
average of crashes in the last 30 start attempts: 0.97
Regards,
Tapomay.
Dear Monet team,
I've been getting quite a bit of use out of your example code here:
http://dev.monetdb.org/hg/MonetDB/file/tip/java/example/SQLcopyinto.java
Recently, though, I ran into a problem. If the "COPY INTO" statement that
I issue is wrong, for example the referenced table doesn't exist, Monet
comes back with an error. The example isn't checking for this error
condition and proceeds to send data anyway. With a really large batch of
data, this becomes a problem because the SQL parser ends up trying to parse
all that data as if it were SQL and basically chokes on it.
The solution is to add something like the following after the out.newLine()
on line 86:
error = in.waitForPrompt();
if (error != null) {
throw new Exception(error);
}
Cheers,
--
Percy Wegmann
+1 512 637 8500 ext 148