Hi,

I am not knowledgeable in these issues, but did you by any chance upgraded monet during your uptime?

what version are you using?

lefteris

On Mon, Nov 23, 2009 at 5:01 PM, Matthew Jones mat@matburt.net wrote:

A little more information... when I start the server without sql and try to initialize it from MAL I get more data:

mal>include sql; MAPI  = datawarehouse@localhost:50000 QUERY = include sql; ERROR = !SQLException:SQLinit:Catalogue initialization failed         !ERROR: Incompatible database version 000000, this server supports version 050000         !ERROR: Please move away /var/MonetDB5/dbfarm/reporting_primary/sql_logs/sql/ and its corresponding dbfarm. #function user.main():void; #    sql.prelude(); #end main;

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 10:43 AM, Matthew Jones mat@matburt.net wrote:

...

Hey folks, had a database running for several weeks without any problems but early this morning anytime a client would try to connect to it the connection would just hang.  After shutting down and restarting I see this:

2009-11-23 09:38:06 MSG merovingian[28036]: starting Merovingian 1.1 for dbfarm /opt/MonetDB5/dbfarm

2009-11-23 09:38:06 MSG merovingian[28036]: listening for TCP connections on 0.0.0.0:50000

2009-11-23 09:38:06 MSG discovery[28036]: listening for UDP messages on 0.0.0.0:50000

2009-11-23 09:38:06 MSG merovingian[28036]: handling commands over UNIX socket /opt/MonetDB5/dbfarm/.merovingian_control

2009-11-23 09:38:06 MSG discovery[28036]: new neighbour 10.1.0.79

2009-11-23 09:38:07 MSG discovery[28036]: new database mapi:monetdb:// hsdw01:50000/reporting_primary (ttl=660s)

2009-11-23 09:39:45 MSG merovingian[28036]: starting database 'reporting_primary' due to control signal

2009-11-23 09:39:45 MSG merovingian[28036]: database 'reporting_primary' has crashed after start on 2009-11-23 09:36:59, attempting restart, up min/avg/max: 2m/2d/1w, crash average: 1.00 0.60 0.27 (18-10=8)

2009-11-23 09:39:46 MSG reporting_primary[28067]: arguments: /usr/bin/mserver5 --config=/etc/monetdb5.conf --dbname=reporting_primary --dbinit=include sql; --set monet_daemon=yes --set mapi_open=false --set mapi_autosense=true --set mapi_port=50001 --set monet_vault_key=/opt/MonetDB5/dbfarm/reporting_primary /.vaultkey

2009-11-23 09:39:46 MSG reporting_primary[28067]: # MonetDB server v5.14.2, based on kernel v1.32.2

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Serving database 'reporting_primary', using 8 threads

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Compiled for x86_64-pc-linux-gnu/64bit with 64bit OIDs dynamically linked

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Copyright (c) 1993-July 2008 CWI.

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Copyright (c) August 2008-2009 MonetDB B.V., all rights reserved

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Visit http://monetdb.cwi.nl / for further information

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Listening for connection requests on mapi:monetdb://127.0.0.1:50001/

2009-11-23 09:39:46 MSG reporting_primary[28067]: # MonetDB/SQL module v2.32.2 loaded

2009-11-23 09:39:46 ERR reporting_primary[28067]: !mvc_init: unable to create system tables

2009-11-23 09:39:55 ERR merovingian[28036]: failed to fork mserver: database 'reporting_primary' has inconsistent state (running but dead), review merovingian's logfile for any peculiarities

The database marks itself as running but any attempt to connect to it returns the following error: monetdb ERROR MALException:setScenario:Scenario not initialized 'sql'

I've read other problems reports that had a similar issue and the suggestion was to wait for the sql module to allow connections but even after 5 minutes this is all that is returned.   Is there any way to get this database back to a consistent state so that it is usable?

73, Matthew W. Jones (KI4ZIB) http://matburt.net

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

Matthew Jones wrote:

A little more information... when I start the server without sql and try to initialize it from MAL I get more data:

mal>include sql; MAPI = datawarehouse@localhost:50000 QUERY = include sql; ERROR = !SQLException:SQLinit:Catalogue initialization failed !ERROR: Incompatible database version 000000, this server supports version 050000 !ERROR: Please move away /var/MonetDB5/dbfarm/reporting_primary/sql_logs/sql/ and its corresponding dbfarm. #function user.main():void; # sql.prelude(); #end main;

Indeed, this indicates that you have installed a new version of MonetDB. One for which a warning was sent out to first dump your database, before installing the new version and loading the database again afterwards.

The feature to make such changes transparent to end-users is high on our list of todos.

regards, Martin

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 10:43 AM, Matthew Jones <mat@matburt.net mailto:mat@matburt.net> wrote:

Hey folks, had a database running for several weeks without any
problems but early this morning anytime a client would try to
connect to it the connection would just hang.  After shutting down
and restarting I see this:

2009-11-23 09:38:06 MSG merovingian[28036]: starting Merovingian 1.1
for dbfarm
/opt/MonetDB5/dbfarm

2009-11-23 09:38:06 MSG merovingian[28036]: listening for TCP
connections on
0.0.0.0:50000 <http://0.0.0.0:50000>

2009-11-23 09:38:06 MSG discovery[28036]: listening for UDP messages on
0.0.0.0:50000 <http://0.0.0.0:50000>

2009-11-23 09:38:06 MSG merovingian[28036]: handling commands over
UNIX socket
/opt/MonetDB5/dbfarm/.merovingian_control

2009-11-23 09:38:06 MSG discovery[28036]: new neighbour 10.1.0.79

2009-11-23 09:38:07 MSG discovery[28036]: new database mapi:monetdb://
hsdw01:50000/reporting_primary (ttl=660s)

2009-11-23 09:39:45 MSG merovingian[28036]: starting database
'reporting_primary' due to control signal

2009-11-23 09:39:45 MSG merovingian[28036]: database
'reporting_primary' has
crashed after start on 2009-11-23 09:36:59, attempting restart, up
min/avg/max:
2m/2d/1w, crash average: 1.00 0.60 0.27 (18-10=8)

2009-11-23 09:39:46 MSG reporting_primary[28067]: arguments:
/usr/bin/mserver5
--config=/etc/monetdb5.conf --dbname=reporting_primary
--dbinit=include sql;
--set monet_daemon=yes --set mapi_open=false --set
mapi_autosense=true --set
mapi_port=50001 --set
monet_vault_key=/opt/MonetDB5/dbfarm/reporting_primary
/.vaultkey

2009-11-23 09:39:46 MSG reporting_primary[28067]: # MonetDB server
v5.14.2,
based on kernel v1.32.2

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Serving database
'reporting_primary', using 8 threads

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Compiled for
x86_64-pc-linux-gnu/64bit with 64bit OIDs dynamically linked

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Copyright (c)
1993-July
2008 CWI.

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Copyright (c) August
2008-2009 MonetDB B.V., all rights reserved

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Visit
http://monetdb.cwi.nl
/ for further information

2009-11-23 09:39:46 MSG reporting_primary[28067]: # Listening for
connection
requests on mapi:monetdb://127.0.0.1:50001/ <http://127.0.0.1:50001/>

2009-11-23 09:39:46 MSG reporting_primary[28067]: # MonetDB/SQL
module v2.32.2
loaded

2009-11-23 09:39:46 ERR reporting_primary[28067]: !mvc_init: unable
to create
system tables

2009-11-23 09:39:55 ERR merovingian[28036]: failed to fork mserver:
database
'reporting_primary' has inconsistent state (running but dead), review
merovingian's logfile for any peculiarities


The database marks itself as running but any attempt to connect to
it returns the following error:
monetdb ERROR MALException:setScenario:Scenario not initialized 'sql'

I've read other problems reports that had a similar issue and the
suggestion was to wait for the sql module to allow connections but
even after 5 minutes this is all that is returned.   Is there any
way to get this database back to a consistent state so that it is
usable?


73,
Matthew W. Jones (KI4ZIB)
http://matburt.net

---

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

---

---

MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

It looks actually that the error is coming from store_init()

Would it be possible for you to run it with gdb and see the values of the parameters of mvc_init(int debug, store_type store, backend_stack stk)

I know thats too much to ask, and I am not en expert on this subject, but it is an interesting situation:) Others may have a better idea than me on this one.

lefteris

On Mon, Nov 23, 2009 at 7:37 PM, Matthew Jones mat@matburt.net wrote:

Martin,  this database was created with the August 2009 SP2 release, it was never upgraded from an old release.   In fact... this database has been running since it was created and started with the August 2009 SP2 release... there has never been any downtime until the whole thing deadlocked last night.

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 1:33 PM, Martin Kersten Martin.Kersten@cwi.nl wrote:

...

Indeed, this indicates that you have installed a new version of MonetDB. One for which a warning was sent out to first dump your database, before installing the new version and loading the database again afterwards.

The feature to make such changes transparent to end-users is high on our list of todos.

regards, Martin

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

On Mon, Nov 23, 2009 at 07:59:11PM +0100, Wouter Alink wrote:

Hi Matthew,

I think I've seen such an error before, but I wasn't able to reproduce it, and therefore did not report it. I think I deleted the old dbfarm and started from scratch as my data was easy to reproduce. I assume less destructive actions are feasible... perhaps deleting the contents in the log folder might help too, but I don't want to be held responsible.

Could you send us the content of your $prefix/dbfarm/$dbname/sql_logs/sql/log file?

Somehow it got corrupted, we are unsure to why this happens.

Niels

Good luck, Wouter

2009/11/23 Matthew Jones mat@matburt.net:

...

Martin,  this database was created with the August 2009 SP2 release, it was never upgraded from an old release.   In fact... this database has been running since it was created and started with the August 2009 SP2 release... there has never been any downtime until the whole thing deadlocked last night.

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 1:33 PM, Martin Kersten Martin.Kersten@cwi.nl wrote:

...

Indeed, this indicates that you have installed a new version of MonetDB. One for which a warning was sent out to first dump your database, before installing the new version and loading the database again afterwards.

The feature to make such changes transparent to end-users is high on our list of todos.

regards, Martin

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

On Mon, Nov 23, 2009 at 02:19:33PM -0500, Matthew Jones wrote:

Hi Niels, interestingly enough.... the 'log' file is totally empty.   So I went back and examined a backup from a few days ago and the contents of the file are:

""" 050000

17623 """

That looks indeed like a correct file. All the latest changes were in the 17623 log file.

By now probably we move on to 22420. Whats the file size of log.22420?

It seems we got corruption somehow when we wrote the new log file. Is the log.22420 the only line (besides the version number) in the log file?

Niels

Which corresponded with a 'log.17623' file that was in the directory at the same time as the backup.

So it looks like maybe the new transaction log file that was hanging around:  log.22420

Can't even be picked up because it is referenced by the 'log' file at the top of sql_logs/sql

Can I recreate this file with the right contents?

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 2:09 PM, Niels Nes Niels.Nes@cwi.nl wrote:

On Mon, Nov 23, 2009 at 07:59:11PM +0100, Wouter Alink wrote:
> Hi Matthew,
>
> I think I've seen such an error before, but I wasn't able to
reproduce
> it, and therefore did not report it. I think I deleted the old
dbfarm
> and started from scratch as my data was easy to reproduce. I
assume
> less destructive actions are feasible... perhaps deleting the
contents
> in the log folder might help too, but I don't want to be held
> responsible.

Could you send us the content of your
$prefix/dbfarm/$dbname/sql_logs/sql/log file?

Somehow it got corrupted, we are unsure to why this happens.

Niels
>
> Good luck,
> Wouter
>
>
>
> 2009/11/23 Matthew Jones <mat@matburt.net>:
> > Martin,  this database was created with the August 2009 SP2
release, it was
> > never upgraded from an old release.   In fact... this database
has been
> > running since it was created and started with the August 2009
SP2 release...
> > there has never been any downtime until the whole thing
deadlocked last
> > night.
> >
> > 73,
> > Matthew W. Jones (KI4ZIB)
> > http://matburt.net
> >
> >
> > On Mon, Nov 23, 2009 at 1:33 PM, Martin Kersten <
Martin.Kersten@cwi.nl>
> > wrote:
> >>
> >> Indeed, this indicates that you have installed a new version
of
> >> MonetDB. One for which a warning was sent out to first dump
> >> your database, before installing the new version and loading
> >> the database again afterwards.
> >>
> >> The feature to make such changes transparent to end-users is
> >> high on our list of todos.
> >>
> >> regards, Martin
> >>
> >
> >
> >
------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports
2008 30-Day
> > trial. Simplify your report design, integration and deployment
- and focus
> > on
> > what you do best, core application coding. Discover what's new
with
> > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > MonetDB-users mailing list
> > MonetDB-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/monetdb-users
> >
> >
>
>
------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports
2008 30-Day
> trial. Simplify your report design, integration and deployment -
and focus on
> what you do best, core application coding. Discover what's new
with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> MonetDB-users mailing list
> MonetDB-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/monetdb-users

--
Niels Nes, Centrum Wiskunde & Informatica (CWI)
Science Park 123, 1098 XG Amsterdam, The Netherlands
room C0.02/M3.46,  phone ++31 20 592-4098
url: http://www.cwi.nl/~niels   e-mail: Niels.Nes@cwi.nl

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports
2008 30-Day
trial. Simplify your report design, integration and deployment -
and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
MonetDB-users mailing list
MonetDB-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/monetdb-users

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

On Mon, Nov 23, 2009 at 02:30:14PM -0500, Matthew Jones wrote:

That actually worked... I recreated that file with the contents that I mentioned below and everything came back up.   Very interesting that that file was empty after the crash.

Great, now I just have to find out why the file was empty.

Niels

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Mon, Nov 23, 2009 at 2:19 PM, Matthew Jones mat@matburt.net wrote:

Hi Niels, interestingly enough.... the 'log' file is totally
empty.   So I went back and examined a backup from a few days ago
and the contents of the file are:

"""
050000

17623
"""

Which corresponded with a 'log.17623' file that was in the
directory at the same time as the backup.

So it looks like maybe the new transaction log file that was
hanging around:  log.22420

Can't even be picked up because it is referenced by the 'log' file
at the top of sql_logs/sql

Can I recreate this file with the right contents?


73,
Matthew W. Jones (KI4ZIB)
http://matburt.net


On Mon, Nov 23, 2009 at 2:09 PM, Niels Nes <Niels.Nes@cwi.nl>
wrote:

    On Mon, Nov 23, 2009 at 07:59:11PM +0100, Wouter Alink wrote:
    > Hi Matthew,
    >
    > I think I've seen such an error before, but I wasn't able to
    reproduce
    > it, and therefore did not report it. I think I deleted the
    old dbfarm
    > and started from scratch as my data was easy to reproduce. I
    assume
    > less destructive actions are feasible... perhaps deleting the
    contents
    > in the log folder might help too, but I don't want to be held
    > responsible.

    Could you send us the content of your
    $prefix/dbfarm/$dbname/sql_logs/sql/log file?

    Somehow it got corrupted, we are unsure to why this happens.

    Niels
    >
    > Good luck,
    > Wouter
    >
    >
    >
    > 2009/11/23 Matthew Jones <mat@matburt.net>:
    > > Martin,  this database was created with the August 2009 SP2
    release, it was
    > > never upgraded from an old release.   In fact... this
    database has been
    > > running since it was created and started with the August
    2009 SP2 release...
    > > there has never been any downtime until the whole thing
    deadlocked last
    > > night.
    > >
    > > 73,
    > > Matthew W. Jones (KI4ZIB)
    > > http://matburt.net
    > >
    > >
    > > On Mon, Nov 23, 2009 at 1:33 PM, Martin Kersten <
    Martin.Kersten@cwi.nl>
    > > wrote:
    > >>
    > >> Indeed, this indicates that you have installed a new
    version of
    > >> MonetDB. One for which a warning was sent out to first
    dump
    > >> your database, before installing the new version and
    loading
    > >> the database again afterwards.
    > >>
    > >> The feature to make such changes transparent to end-users
    is
    > >> high on our list of todos.
    > >>
    > >> regards, Martin
    > >>
    > >
    > >
    > >
    ------------------------------------------------------------------------------
    > > Let Crystal Reports handle the reporting - Free Crystal
    Reports 2008 30-Day
    > > trial. Simplify your report design, integration and
    deployment - and focus
    > > on
    > > what you do best, core application coding. Discover what's
    new with
    > > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
    > > _______________________________________________
    > > MonetDB-users mailing list
    > > MonetDB-users@lists.sourceforge.net
    > > https://lists.sourceforge.net/lists/listinfo/monetdb-users
    > >
    > >
    >
    >
    ------------------------------------------------------------------------------
    > Let Crystal Reports handle the reporting - Free Crystal
    Reports 2008 30-Day
    > trial. Simplify your report design, integration and
    deployment - and focus on
    > what you do best, core application coding. Discover what's
    new with
    > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
    > _______________________________________________
    > MonetDB-users mailing list
    > MonetDB-users@lists.sourceforge.net
    > https://lists.sourceforge.net/lists/listinfo/monetdb-users

    --
    Niels Nes, Centrum Wiskunde & Informatica (CWI)
    Science Park 123, 1098 XG Amsterdam, The Netherlands
    room C0.02/M3.46,  phone ++31 20 592-4098
    url: http://www.cwi.nl/~niels   e-mail: Niels.Nes@cwi.nl

    ------------------------------------------------------------------------------
    Let Crystal Reports handle the reporting - Free Crystal Reports
    2008 30-Day
    trial. Simplify your report design, integration and deployment
    - and focus on
    what you do best, core application coding. Discover what's new
    with
    Crystal Reports now.  http://p.sf.net/sfu/bobj-july
    _______________________________________________
    MonetDB-users mailing list
    MonetDB-users@lists.sourceforge.net
    https://lists.sourceforge.net/lists/listinfo/monetdb-users

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

Memory tests were run and no problems were reported. With MonetDB+bad memory I would expect to lose some data and no data was lost here.

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Tue, Nov 24, 2009 at 8:59 AM, Sam Mason sam@samason.me.uk wrote:

On Mon, Nov 23, 2009 at 08:35:49PM +0100, Niels Nes wrote:

...

On Mon, Nov 23, 2009 at 02:30:14PM -0500, Matthew Jones wrote:

...

That actually worked... I recreated that file with the contents that I mentioned below and everything came back up. Very interesting that that file was empty after the crash.

Great, now I just have to find out why the file was empty.

This couldn't be a case of bad memory could it? I'm more of a user of Postgres and it happens surprisingly often there---i.e. PG misbehaves, user goes away and runs a RAM tester and it reports some bad memory.

Symptoms are about right; code running for a reasonable amount of time with what (in my experience, but not sure if this applies here) is normally a regular workload and spontaneously something breaks.

-- Sam http://samason.me.uk/

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

I tend to look at software problems before I look at hardware problems... I'm much more inclined to believe that the deadlock was a mutex issue and the timing of it happening caused the transaction log record file to be truncated. Hits on memory from cosmic rays? That's rather grandiose... I think you should go re-read Occam's Razor.

73, Matthew W. Jones (KI4ZIB) http://matburt.net

On Tue, Nov 24, 2009 at 9:55 AM, Sam Mason sam@samason.me.uk wrote:

On Tue, Nov 24, 2009 at 09:42:08AM -0500, Matthew Jones wrote:

...

Memory tests were run and no problems were reported. With MonetDB+bad memory I would expect to lose some data and no data was lost here.

You lost the contents of one file didn't you? Hits on memory from cosmic rays cause random single bit flips at a small but measurable rate--though ECC memory should help. These could cause something in Linux's page buffer to go awry and hence ending up with an empty file when unexpected. The bug rate of normal software means that that these sorts of errors are almost completely masked, however when code matures these sorts of errors start to become important. I'm not sure if Monet is stable enough to think about this yet, but if you've got a stable access pattern that only hits exactly the same code paths then it shouldn't matter about the remaining bugs.

Higher assurance software tends to include checksums and other simple invariants that are checked at various places in code to make sure that errors like this aren't propagated too far.

-- Sam http://samason.me.uk/

---

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ MonetDB-users mailing list MonetDB-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/monetdb-users

On Mon, Nov 23, 2009 at 08:11:54PM +0100, Fabian Groffen wrote:

On 23-11-2009 19:33:06 +0100, Martin Kersten wrote:

...

Matthew Jones wrote:

...

ERROR = !SQLException:SQLinit:Catalogue initialization failed !ERROR: Incompatible database version 000000, this server supports version 050000 !ERROR: Please move away

Indeed, this indicates that you have installed a new version of MonetDB. One for which a warning was sent out to first dump your database, before installing the new version and loading the database again afterwards.

It looks more like something got corrupt ( :( ), since version 000000 most probably isn't the previous one to 050000.

how about version 000000 is actually not read from the log, but the initial value in the code; the same error message is printed both when a version number cannot be read (correctly) from the log file and when the read version number does not match the supported one; cf. MonetDB/src/gdk/gdk_logger.mx ======== static int check_version(logger *lg, FILE *fp) { int version = 0;

if (fscanf(fp, "%6d", &version) != 1 || version != lg->version) { GDKerror("Incompatible database version %06d, " "this server supports version %06d\n" "Please move away %s and its corresponding dbfarm.", version, lg->version, lg->dir);

return -1; } fgetc(fp); /* skip \n */ fgetc(fp); /* skip \n */ return 0; } ========

Maybe, splitting the error message in two, one for fscanf() failure and one for non-matching version number might help to avoid confusion in future cases ...

Stefan