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