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
