Vlad,
Jim only mentioned using this version for identification. You are
talking about upgrades, but we don't have any of those. If we did have
an automatic upgrade of the data or format in a tablespace, then we
would need something to compare with to know if it can be done. Once an
upgrade is done on a tablespace, the ODS version numbers should change
as well.
That may be in the future. Major and minor version numbers will be more
usefull for any automagic tinkering we can do. But these strings I
mentioned get changed more often than releases and ODS version changes.
If we are diagnosing a bug or a failed recovery in a zipped up data
directory, it would be very usefull to be able to match up the files
with the code that made them.
Maybe we should include both numbers and strings?
This number is already in the tablespace header.
static const int INDEX_CURRENT_VERSION = INDEX_VERSION_1;
Some other possible numbers to include;
ODS_VERSION
ODS_MINOR_VERSION
VERSION_CURRENT
VERSION_SERIAL_LOG
FALCON_VERSION
FALCON_DATE
We do not have the server release version numbers available within
Falcon currently. Do you think that is necessary? If Falcon can become
a truly pluggable engine, then only the Falcon version number matter.
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.
>>
>
