List:Falcon Storage Engine« Previous MessageNext Message »
From:Kevin Lewis Date:November 4 2008 4:25am
Subject:Re: SRLSession and Server Version Number
View as plain text  

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.

Some other possible numbers to include;

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.
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