And I probably should take the other part of the documentation out there more seriously. I guess this is 'suppose' to happen if you do *not* include geom in your (jfu) database. gdb --args /opt/monetdb/bin/mserver5 --dbinit="include sql;" --dbname=osm --dbfarm=/mnt/media/MonetDB5/dbfarm GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /opt/monetdb/bin/mserver5 --dbinit=include\ sql\; --dbname=osm --dbfarm=/mnt/media/MonetDB5/dbfarm warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff30ffd000 [Thread debugging using libthread_db enabled] [New Thread 0x2b887c85d860 (LWP 2919)] [New Thread 0x40800950 (LWP 2922)] # MonetDB server v5.3.0, based on kernel v1.21.0 # Serving database 'osm' # Compiled for x86_64-unknown-linux-gnu/64bit with 64bit OIDs dynamically linked # Copyright (c) 1993-2007 CWI, all rights reserved # Visit http://monetdb.cwi.nl/ for further information #warning: please don't forget to set your vault key! #(see /opt/monetdb/etc/monetdb5.conf) [New Thread 0x41001950 (LWP 2923)] # Listening for connection requests on mapi:monetdb://127.0.0.1:50000/ # MonetDB/SQL module v2.21.0 loaded

!ERROR: BATnew:tt error

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x41001950 (LWP 2923)] 0x00002aaab26c8d3c in temp_create (b=0x0) at bat_utils.mx:130 130 temp_dup(b->batCacheid); (gdb) bt #0 0x00002aaab26c8d3c in temp_create (b=0x0) at bat_utils.mx:130 #1 0x00002aaab26c4d76 in e_bat (type=-31) at bat_storage.mx:84 #2 0x00002aaab26c62ee in load_bat (sname=0xba3028 "sys", tname=0x10607d8 "nodes_geom", bname=0x107d118 "geometry", type=-31, sz=1024, cnt=0x1060700) at bat_storage.mx:454 #3 0x00002aaab26c6660 in create_col (tr=0xba2ee8, c=0x107d088) at bat_storage.mx:518 #4 0x00002aaab26b639b in load_column (tr=0xba2ee8, t=0x10606c8, rid=193) at store.mx:516 #5 0x00002aaab26b691c in load_table (tr=0xba2ee8, s=0xba2f58, rid=193) at store.mx:583 #6 0x00002aaab26b7dd3 in load_schema (tr=0xba2ee8, id=1128, rid=38) at store.mx:850 #7 0x00002aaab26b819e in load_trans (tr=0xba2ee8, id=1128) at store.mx:902 #8 0x00002aaab26ba16d in store_init (debug=0, store=store_bat, logdir=0x63cfc0 "/opt/monetdb/var/MonetDB5/sql_logs", dbname=0x63ce90 "osm", stk=0) at store.mx:1328 #9 0x00002aaab269707d in mvc_init (debug=0, store=store_bat, stk=0) at sql_mvc.mx:247 #10 0x00002aaab26367bb in SQLinit (c=0x6046c8) at sql_scenario.mx:227 #11 0x00002b8879e003af in initScenario (c=0x6046c8, s=0x2b887a01b070) at mal_scenario.mx:263 #12 0x00002b8879e0159c in setScenario (c=0x6046c8, nme=0xad8123 "sql") at mal_scenario.mx:471 #13 0x00002b8879dc9951 in MSscheduleClient (command=0xad80e8 "LIT", challenge=0x41000fc0 "Roh8IvYDJa", fin=0xacdf40, fout=0xacdea0) at mal_session.mx:342 #14 0x00002aaab0f8527b in doChallenge (cmd=0x0, in=0xacdd60, out=0xacdcc0) at mserver.mx:481 #15 0x00002aaab0f85533 in SERVERlistenThread (Sock=0x9f0938) at mserver.mx:563 #16 0x00002b887b8d5067 in start_thread () from /lib/libpthread.so.0 #17 0x00002b887c5d9bed in clone () from /lib/libc.so.6 People may wonder why I tried anyway... The simple query "select * from nodes LIMIT 1;" also took far more time (22s) to complete than expected. Stefan