Issue Details (XML | Word | Printable)

Key: CORE-1300
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Vlad Khorsun
Reporter: Vlad Khorsun
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Firebird Core

Lower level index pages is missed from parent page

Created: 03/Jun/07 07:28 AM   Updated: 22/Aug/16 05:48 AM
Component/s: Engine
Affects Version/s: 2.0.1, 2.1 Initial
Fix Version/s: 2.1 Beta 1, 2.0.2

Environment: It was reproduced on ODS11 but it may happen on older ODS too i think. Problem code is present from the day one
Issue Links:

QA Status: Cannot be tested

Sub-Tasks  All   Open   

 Description  « Hide
Sometimes parent page missed nodes pointed at lower level pages.
For example parent page have nodes A, B while at lower level pages linked as A, C, B

This error can be detected by gfix. It reports in firebird.log 2 errors for the same index page for each such case :

Index XXX is corrupt on page YYY level 1. File: \Fb2\fb2.0\src\jrd\validation.cpp, line: 1656
Index XXX is corrupt on page YYY level 1. File: \Fb2\fb2.0\src\jrd\validation.cpp, line: 1646

(line number as per 2.0 sources)

This error itself can't lead to wrong query results, AFAIK, but i don't know if it can lead to more serious corruptions being present in actively modified index for a long time.

Also this bug can produce 'wrong page type expected 7 found XXX' bugchecks

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 03/Jun/07 07:31 AM
Both bugs reported by gfix similarly and was found using the same test case

Vlad Khorsun added a comment - 03/Jun/07 12:04 PM
Below is explanation of a bug and solution :

When we add an entry into the index we search through b-tree branch down to leaf page, insert node there and if leaf page splits we add new page number at one level upper.

Upper page number is remembered in variable ("index" in add_node) before we do handoff from this page down to leaf page

After that we re-fetch upper page by remembered page number and add split page number into it. Note - we don't retain lock at upper page while inserting key into leaf page

But this upper page can be removed from index when we finish split at lower level - thus we will insert split page number into removed page

If this removed page is re-allocated at this point (not a case for this bug report) then we may have 'wrong page type expected 7 found xxx' error if it re-allocated as non-index page. In my test case this page is not allocated thus i have it completed without such errors

I can offer 3 ways to solve the issue :

a) mark parent page with btr_dont_gc flag before CCH_HANDOFF and clear this mark after return from add_node

Easy to implement but make additional page fetches with LCK_write lock which is not necessary in most cases.

b) retain LCK_read lock on parent page, replace CCH_HANDOFF by CCH_FETCH and remove last CCH_FETCH

Also easy to implement but retain more that one page locked. I doubt it can lead to deadlocks as page locks acquired in strong order and we have similar locking schema in btr\garbage_collect

c) detect parent page change and search for correct insertion point starting from root page

Harder to implement and will be not necessary for most cases as parent page can be changed many times and still stay in index at its original place

I've implemented both (a) and (b) and found that (b) is much worse from performance POV.
Ann also prefer (a). So solution (a) is committed into CVS

maziar added a comment - 24/Nov/07 11:49 PM
i dont sure is fix i continiue in firebird 2.
1beta 2 i see this error !

Vlad Khorsun added a comment - 25/Nov/07 02:38 AM
Without reproducible example i'm afraid i can't do much more than already done