gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Bootstrap problems


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Bootstrap problems
Date: Mon, 5 Nov 2007 00:34:24 +0100
User-agent: Mutt/1.5.16 (2007-06-11)

On Sun, Nov 04, 2007 at 11:09:57PM +0100, Helge wrote:

>> Can you mail us the complete bootstrap logs ? You can mail
>> me in private if you wish.
> Yes I enclose all the files.
Thanks. I'll take this back on-list for the benefit of
onlookers if any.

>> Something went wrong with creating the v2 database.

...

> 2007-11-04 20:45:31  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-Julian_Bashir.sql]
> 2007-11-04 20:45:32  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-James_Kirk.sql]
> 2007-11-04 20:45:32  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-lab_regression.sql]
Well, it gets this far which should mean it worked so lets
see if we can find anything fishy:

> 2007-11-04 20:44:10    
> ------------------------------------------------------------
> 2007-11-04 20:44:10  [INFO]   
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmLog.py:address@hidden):
>   SECURITY: initial log level is [INFO]  
> 2007-11-04 20:44:10  [INFO]   
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmLog.py:address@hidden):
>   instantiated log file 
> [/home/helge/gnumed/gnumed-server/GNUmed-v7/server/bootstrap/bootstrap-latest-v2.log]
>  with ID 
> [/home/helge/gnumed/gnumed-server/GNUmed-v7/server/bootstrap/bootstrap-latest-v2.log]
>  

...

> 2007-11-04 20:44:15  [INFO]   
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPG2.py:address@hidden):
>   PostgreSQL version (numeric): 8.1
While this is OK is there any specific reason you don't use
PG 8.2 ? In case you need to search for patient names
containing diacritics or umlauts 8.1 may give you some
trouble (because for example lower('Ö') maps to '').

> 2007-11-04 20:44:36  [DATA]   
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPsql.py:address@hidden):
>   drop schema gm cascade
> 2007-11-04 20:44:36  [DATA]   
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPsql.py:address@hidden):
>   ../sql/gmConcatTableStructureFutureStub.sql:17: schema "gm" does not exist
> 2007-11-04 20:44:37  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/gmConcatTableStructureFutureStub.sql]
Good. The hash functions got properly transitioned to their own schema.

> 2007-11-04 20:45:29  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> installed PostgreSQL version: [8.1] - this is fine with me
> 2007-11-04 20:45:29  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/gmDemographics-Person-test_data.sql]
> 2007-11-04 20:45:30  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-Leonard_McCoy.sql]
> 2007-11-04 20:45:30  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-Spock.sql]
> 2007-11-04 20:45:30  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-USS_Enterprise.sql]
> 2007-11-04 20:45:31  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-Christine_Chapel.sql]
> 2007-11-04 20:45:31  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-Julian_Bashir.sql]
> 2007-11-04 20:45:32  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-James_Kirk.sql]
> 2007-11-04 20:45:32  [INFO]   (./bootstrap_gm_db_system.py:address@hidden):  
> successfully imported [../sql/test-data/test_data-lab_regression.sql]
OK, everything seems fine so far. But then ...

> 2007-11-04 20:45:38  [ERROR]  
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPG2.py:address@hidden):
>   database schema version mismatch
> 2007-11-04 20:45:38  [ERROR]  
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPG2.py:address@hidden):
>   expected: v2 (b09d50d7ed3f91ddf4c4ddb8ea507720)
> 2007-11-04 20:45:39  [ERROR]  
> (/home/helge/gnumed/gnumed-server/GNUmed-v7/Gnumed/pycommon/gmPG2.py:address@hidden):
>   detected: unknown database schema version, MD5 hash is 
> [49ddcefbe86483778bd6e0797cab73e0] (49ddcefbe86483778bd6e0797cab73e0)
> 2007-11-04 20:45:39  [ERROR]  (./bootstrap_gm_db_system.py:address@hidden):  
> target database identity hash invalid
> 2007-11-04 20:45:39  [ERROR]  (./bootstrap_gm_db_system.py:address@hidden):  
> Bootstrapping failed: wrong result hash
While everything above seemed OK the hash isn't what was
expected. Now, that might be because we didn't detect the
failure or because the hash is calculated wrongly for some
reason. I suspect the latter. Would you mind mailing the
results of:

select gm.concat_table_structure();

At the v2 stage we are still including the "public" schema
with the database structure hash (which we have migrated
away from). Some database admin tools pride(d) themselves in
installing their own tables in the "public" schema of each
database. So, in case you had used on of these on the
"template1" database those tables got cloned to gnumed_v2
and throw our (old) hash function off balance.

Another possibility might be that PG 8.1 being more advanced
in locale issues might affect sorting in unexpected ways
thereby influencing the hash - although it is known to work
on other 8.1 installations and we also guard against that by
ordering on md5()s rather than on the raw strings. But you
never know.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]