Re: [Gnumed-devel] Corrupt database

[Busser, Jim]

On 2013-05-30, at 11:12 PM, Karsten Hilbert <address@hidden> wrote:

>> Can it be assumed that if the schema can be successfully queried, and that 
>> it matches the hash of the reference fingerprint, that the file is not 
>> corrupted?
> No, and in fact, there are many files making up one database.

In this case, exists there any postgres maintenance function or utility that 
can test and report the integrity or non-integrity of the database?


>> Would it make sense to automate this check of fingerprints as part of the 
>> backup procedure?
> 
> Refuse to back up and/or restore if there is a database mismatch ?

The above could keep a record of when something about the database had been 
changed. This could help someone to target a date or range of dates when they 
might have been in communication with someone about a problem that they were 
having with their database, and may point them to the change that they had made 
(such as altering a constraint) which they can no longer recall what they did.

> 
>> This might involve to keep, in the backup directory, a copy of whatever is 
>> the desired reference fingerprint.
> 
> What use do you have in mind ?  One thing I can imagine is including
> "corrupted_schema" in the backup filename if so.

see my question below

>> The result of the script could append a line onto the end of a backup file 
>> say
>> 
>>      fingerprint.check
>> 
>> with
>> 
>>      datetime version_current hashvalue_current version_reference 
>> hashvalue_reference
>>      Tue 28 May 2013 19:01:02 PDT gnumed_v18 
>> a0f9efcabdecfb4ddb6d8c0b69c02092 gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092
>>      Wed 29 May 2013 21:01:02 PDT gnumed_v18 
>> a0f9efcabdecfb4ddb6d8c0b69c02092 gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092
>>      Thu 30 May 2013 20:04:09 PDT gnumed_v18 
>> z6f7a1428e7c83f4bf638c3a1146e93s gnumed_v18 a0f9efcabdecfb4ddb6d8c0b69c02092
> 
> What would be the benefit ?  Given that the client verifies the hash every 
> single time
> it is started I dare say the user would learn of mismatches very quickly w/o 
> keeping
> a log of hashes.

When the hash mismatches, will the client refuse to run? Or will it simply warn?

If the client will refuse to run, then I am not sure that to have captured when 
the fingerprint changed will be useful, since that will no doubt have occurred 
between the time that records had been added to the database via client, and 
when the client refused to run.

-- JIm