False index corruption (CORE-3916)

By Pavel Cisar

When database validation reports index corruption, check your engine version.

If you are still using Firebird version 2.5.1 or 2.5.2 and gfix reports index corruption in the form of "Index X is corrupt (missing entries) in table Y", check the number of rows in the affected table (Y). If there is a large amount of rows (hundreds of millions), it's likely that your database is in good shape and you're victim of rare bug in the database validation code. Simply put, it could be false alarm.

This particular bug (CORE-3916) in the database validation code is trivial. Some time ago SLONG variables were replaced by a RecordNumber structure that could store record number values higher than 2^32, but the database validation code wasn't updated to reflect this.

This omission was corrected in version 2.5.3. This mistake surfaces only when slot number (see description of a Data Page used by particular table exceeds 2^31.

In an ideal case where the number of slots would be equal to number of rows stored in table, this error will surface only on tables with 2,147, 483,648 or more rows. However, in practice such a slot number could be reached with less real records (rows). The exact ratio depends on how the data fits on a Data Page (which is related to page size and length of stored data for every record), whether reserve space is enabled or not, and how many BLOBs are defined for the table.

So in real world you may see this error when you reach several hundred millions of rows.

It's easy to verify whether you're facing real index corruption or this false alarm - use Firebird 2.5.3 or newer to run database validation again and check whether index corruption is still reported or not.


You need to use 2.5.3 engine (server), not just gfix taken from the 2.5.3 distribution package, because it's the engine that performs the actual validation, not the gfix tool.