List:Falcon Storage Engine« Previous MessageNext Message »
From:Jim Starkey Date:November 4 2008 7:31pm
Subject:Re: SRLSession and Server Version Number
View as plain text  
Believe me, it is extremely useful to know how ancient a database was.  
We have lots of mechanisms for upward compatibility.  Knowing which 
might have been active is a critical piece of information when analyzing 
a bug.  Knowing the original creation version (from the database header) 
and the crash version (from the SRLSession) is even better.

I do agree that a concise, comparable 32 bit word is better than a 
string.  Perhaps maintaining a Falcon build number would be useful.

Netfrastructure has a version maintenance program (Version.cpp) that 
reads and generates NetfraVersion.h, with options to bump the major 
version, minor version, or release type.  It also maintains a build 
number, which is just what we want, and a log file listing version 
strings, build numbers, and dates.

I notice that the Falcon NetfraVersion.h reflects a date of May 02, 
2006, which suggests that it might not be up to date.

I hate to make cutting kits more complicated, but running the version 
maintenance program after major changes and before releases would give 
us a very good way to correlate a database with a history.

The version program is certainly in the MySQL Netfrastructure tree.  I 
have it in my source tree, and would be happy to send it to anyone who 
wanted to take it on.



Vladislav Vaintroub wrote:
>> #define FALCON_VERSION	"T1.3-2"
>> #define FALCON_DATE	"30 October, 2008"
>>     
>
> Frankly, I do not find this format any useful.numbers  and dates are
> maintained manually, while we could get something better suited for > <
> comparison from the build team e.g major,minor,release version of MySQL as
> numbers. Also, strings aren't that well suited for persistent storage,
> because of variable length.
>
> Also, putting versions into tablespace does not seem to make much sense to
> me, unless they are updated together with database upgrades. Imagine you got
> 6.0.4 in your tablespace. It says nothing, database could be upgraded 4
> times since then, or maybe 3 or 2 times. However, version numbers in
> tablespace could be useful to identify upgrade point, i.e first time
> executable version does not match serial log version  it is an upgrade (or
> maybe downgrade).In this scenario however, version needs to be updated in
> the tablespace header within the same session, otherwise each subsequent
> restart will be considered an upgrade-restart.
>
>
> -----Original Message-----
> From: Kevin.Lewis@stripped [mailto:Kevin.Lewis@stripped] 
> Sent: Tuesday, November 04, 2008 1:54 AM
> To: Vladislav Vaintroub
> Cc: falcon@stripped
> Subject: Re: SRLSession and Server Version Number
>
> Vlad,
>
> This seems like a good idea to me since it is backward compatible and 
> will help to diagnose future recovery problems by knowing for sure what 
> version of Falcon created the tablespace and the serial log.  Would you 
> take on this task as part of your recovery investigations?  Unless you 
> can find a reason to do it under a bug, please open a worklog to track it.
>
> I think we are talking about using putStream to add these
>
> #define FALCON_VERSION	"T1.3-2"
> #define FALCON_DATE	"30 October, 2008"
>
> in SRLSession::append() and getStream() in SRLSession::read().
>
> Then they can be added to the end of the header page in Hdr::create()
>
>
>
> Jim Starkey wrote:
>   
>> Maybe we should put the server version number in a) the database header 
>> and b) the serial log session (SRLSession) record.  This would give us 
>> an accurate idea of a database's history.
>>
>> The database header page, incidentally, is initialized as zero, so 
>> adding stuff is trivial and backward compatible.
>>
>>     
>
>   


-- 
Jim Starkey
President, NimbusDB, Inc.
978 526-1376

Thread
SRLSession and Server Version NumberJim Starkey4 Nov
  • Re: SRLSession and Server Version NumberKevin Lewis4 Nov
    • RE: SRLSession and Server Version NumberVladislav Vaintroub4 Nov
      • Re: SRLSession and Server Version NumberKevin Lewis4 Nov
        • Re: SRLSession and Server Version NumberJames Day5 Nov
          • Re: SRLSession and Server Version NumberAnn W. Harrison5 Nov
            • Re: SRLSession and Server Version NumberJim Starkey5 Nov
      • Re: SRLSession and Server Version NumberJim Starkey4 Nov