There is another interesting case of phase1 use that does not correspond to
schema outlinesd in Chris' documentation.
I'm talking about SRLDeleteIndex::pass1(). It does exactly the same what
SRLDeleteIndex::commit() does, namely IndexRootPage::deleteIndex().
Anyone knows the reason? Should not that be in redo() instead of pass1()?
> -----Original Message-----
> From: Vladislav.Vaintroub@stripped [mailto:Vladislav.Vaintroub@stripped]
> On Behalf Of Vladislav Vaintroub
> Sent: Friday, November 07, 2008 2:45 PM
> To: 'FalconDev'
> Subject: Question on The 3 phases Of Recovery
>
> Hi,
> Since I cannot find a good Falcon internals documentation and cannot
> make
> use of sparse comments,
> I fallback to Chris' blog that explains Falcon recovery (Chris, much
> thanks
> for putting docu on the Web:)):
>
> Phase I: Take Inventory, Establish State
> - Determine transaction states
> - Determine object states (track state transitions, record final state)
> - Determine the last checkpointed record (prior objects guaranteed on
> disk)
>
> Phase II: Physical Allocation
> - Allocate and release required pages and sections
> - Track object "incarnation" and state--update active objects with last
> incarnation
>
> Phase III: Logical Application
> - Apply data and index changes (avoid reallocating pages in use)
>
>
> In case I'm investigating right now I've got following backtrace
> PageInventoryPage::reallocPage
> Dbb::reallocPage
> SerialLog::bumpPageIncarnation
> SRLSectionPage::pass1
>
>
> How does this correspond to the description of Phase I? Should not
> reallocPages be done first in Phase II?
>
> Vlad
>
>
> --
> Falcon Storage Engine Mailing List
> For list archives: http://lists.mysql.com/falcon
> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
