Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875) Bug#38186, Bug#39789

[Jim Starkey]

Vladislav Vaintroub wrote:
>   
>> -----Original Message-----
>> From: Ann.Harrison@stripped [mailto:Ann.Harrison@stripped] On Behalf Of
>> Ann W. Harrison
>> Sent: Thursday, October 23, 2008 9:41 PM
>> To: Vladislav Vaintroub
>> Cc: Kevin.Lewis@stripped; 'Vladislav Vaintroub';
>> commits@stripped; 'Falcon Team'
>> Subject: Re: bzr commit into mysql-6.0-falcon-team branch
>> (vvaintroub:2875) Bug#38186, Bug#39789
>>
>> Vlad,
>>
>>     
>>> Keep in mind, that all possible tablespaces are created in memory and
>>>       
>> on
>>     
>>> disk during pass1() or in Tablespace::boostrap(). They are never
>>>       
>> deleted
>>     
>>> until REDO phase comes. REDO does not recreate Tablespaces - why
>>>       
>> should it,
>>     
>>> they are already present after the pass1.
>>>       
>> That's not what I would expect.  All possible tablespaces should
>> be tracked in memory during pass1, but only the ones that will
>> survive at the end should ever be created.  The other should be
>> marked as old instantiations, and all actions on them should be
>> skipped after pass1.
>>
>>     
> First, while running pass1 it is not known beforehand if tablespace will
> exist at the end or not. For simplicity, we could assume that the same
> tablespaces that are present before recovery will be present after that and
> no new tablespaces will be created (I cannot come up you have a
> counterexample).
>
> So let's try not creating any tablespaces in any pass, only open existing
> ones. 
>
> I tried that just now and what happens is an exception here
> 	mysqld.exe!TableSpaceManager::getTableSpace(int id=3)  
> 	mysqld.exe!SerialLog::getDbb(int tableSpaceId=3)
>  	mysqld.exe!SerialLog::bumpPageIncarnation(int pageNumber=2, int
> tableSpaceId=3, int state=1)  
> 	mysqld.exe!SRLSectionPage::pass1()
>
> Ok, this tablespace was probably created and removed but how do we know that
> until we've seen SRLDropTablespace.
> We can theoretically create special exception "no tablespace" and ignore it
> / switch to the next record during all phases of recovery.
> Sounds wacko, but could work. (In this "design"  SRLCreateTableSpace and
> SRLDropTableSpace are dummies, they do nothing)
>
> Otherwise I would not know how to accomplish "and all actions on them should
> be skipped after pass1." There is no tablespace id in  SerialLogRecord,
> which I could use to skip the record. There is tablespace id for some record
> types, but generally there is none and editing 37 SRLSomething classes and
> account for missing dataspace in each one sounds much like asking for
> trouble.
>   

Probably the best way to handle the problem is to take inventory of 
tablespace creation and deletion during pass1, deferring actual file 
deletion and creation (if necessary) to pass2 when you know what is 
actually going on.  Comparing filenames is too problematic, so trying to 
open the file and get either a file id or canonical file name is the way 
to go.  It should be trivial to determine the correct action during pass 2.

I think you will find that all table space related SRL record types 
already carry tablespace id, both for incarnation checking and for find 
the tablespace the update is to be applied to.

In general, it is better to follow the established architecture than 
inventing new mechanisms without a compelling reason.  Using pass1 to 
take inventory, pass2 to handle physical updates, and pass 3 to apply 
logical updates works pretty well.  If we find something that requires 
changing the architecture, then we shouldn't hesitate to do so, but I 
don't think that is the case here.  If you think otherwise, please 
explain the reasons.