Recovery and Page IO bugs classified by Vlad

[Christopher Powers]

Wiki-ized for your convenience: https://inside.mysql.com/wiki/FalconBugs

Updated Op-Center: https://inside.mysql.com/wiki/FalconOpCenter


Vladislav Vaintroub wrote:
> Hello,
> Here is my classification of falcon recovery bugs, those with F_RECOVERY. As
> I see it, we have 4 real recovery bugs, near the end (or 6 if I count
> duplicates).
> 
> 
> Category : Persistency bug (not recovery)
> http://bugs.mysql.com/bug.php?id=42903 
> Bug #42903 Falcon: Inconsistent tablespace after recovery. 
> Short description : Not a recovery bug. 
> Difference in queries that supposed to return the same results. Classified
> as index inconsistence. Search with simpler queries on the same tablespaces
> normally does not reveal inconsistencies (but one counterexample produced
> without recovery is attached).
> Suspected cause: don't know.
> Suggested fix: no clue.. Tried to reproduce, all data that was reporting as
> missing from index, was there (found using simpler queries)
> 
> 
> Category: Undebuggable one time glitch.
> http://bugs.mysql.com/bug.php?id=39703 
> Bug #39703 Assertion in Section.cpp failed during recovery after
> falcon_limit test
> Short description. seen in September. Crash dump is not usable for anyone
> but Olav (Sparc, wrong endian).
> Possible fix:
>   Close as none-reproducible
> 
> 
> 
> Category: Won't fix 
> http://bugs.mysql.com/bug.php?id=39130 
> Bug #39130 Unbounded serial log growth with online ALTER
> Short description: discussion on how gophers can lag behind
> Suspected cause: gophers lag behind
> Suggested fix: won't fix (works as designed)
> 
> http://bugs.mysql.com/bug.php?id=36993 
> Bug#39139 Falcon reports Index SCHEDULE..PRIMARY_KEY in SYSTEM.SCHEDULE
> damaged
> Suspected cause:
>  Kill -9 before system tables were completely created.
> Suggested fix: won't fix (good workaround)
> Workaround: delete all falcon spaces and serial logs.
> 
> 
> Category: Real bugs
> http://bugs.mysql.com/bug.php?id=44096 
> Bug #44096 Exception: Recovery failed: corrupted serial log
> Short description: after truncation, serial log cannot be recovered (Falcon
> does not know where to start)
> 
> http://bugs.mysql.com/bug.php?id=41840 
> Bug #41840 Unbounded tablespace growth during recovery
> Was shortly inspected in Athens.
> Short description: lost pages.
> Suspected cause :
>   Pageoverflow pages are lost. Recovery does not do anything with
> SRLOverflowPages
> Possible fix:
>   Delete those pages in recovery (phase3).
> 
> http://bugs.mysql.com/bug.php?id=43106 
> Bug #43106 Falcon recovery assertion (bdb->buffer->pageNumber == pageNumber)
> in Cache.cpp 
> Short description: 
>  page of all zeros encountered while datapage is expected during redo of
> blob delete.
>  Hardly reproducible, usable tablespace attached.
> Suspected cause:
>  Blob datapage not logged (Ann, Kevin - that sounds familiar, right:)?)
> 
> 
> http://bugs.mysql.com/bug.php?id=43502 
> Bug #43502 Falcon assertion (idx->offset == 0 || (idx->offset >= indexEnd
> ... 
> Sort description:  Datapage corruption and its duplicates. May or may not be
> not recovery specific.
> Duplicates : http://bugs.mysql.com/bug.php?id=44162 (Bug #44162 Falcon
> recovery error DataPage::computeSpaceAvailable got a negative number)
>              http://bugs.mysql.com/bug.php?id=43503 (Bug #43503 Falcon
> attempting to access exorbitant page number during recovery)
> Possible fix: Assign to Ann, she knows the datastructures best. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>