List:Commits« Previous MessageNext Message »
From:Vladislav Vaintroub Date:October 24 2008 1:28am
Subject:RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)
Bug#38186, Bug#39789
View as plain text  

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


> > IF they are not present during pass1 or pass2, we ultimately suck
> during in
> > recovery on IO::read().
> 
> What is IO::read() reading?

Sorry, probably mixed with getDbb(int tableSpaceId). Nothing with IO.



Thread
bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875) Bug#38186,Bug#39789Vladislav Vaintroub21 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub23 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub23 Oct
  • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Ann W. Harrison23 Oct
    • RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct
      • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Jim Starkey24 Oct
        • RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct
          • Re: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Jim Starkey26 Oct
RE: bzr commit into mysql-6.0-falcon-team branch (vvaintroub:2875)Bug#38186, Bug#39789Vladislav Vaintroub24 Oct