Issue Details (XML | Word | Printable)

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

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

Blobs garbage collector removed wrong blob if going blob descriptor contains 0:0 (NULL value) but field's NULL flag is not set

Created: 07/May/07 04:54 AM   Updated: 19/Jan/16 05:07 AM
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.1 Beta 1, 2.0.2

Environment: FB 2.0.1 and in builds of FB 2.1.0 after Alpha 1 since 2007-03-23

QA Status: No test

 Description  « Hide
Error showed himself after 64-bit alignment issues was fixed as new code assumed correct relation_id in blob_id
This error can happen only because of direct modifications in system tables

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Martijn Tonies added a comment - 07/May/07 05:09 AM

What direct modification of the system tables are we talking about?

Vlad Khorsun added a comment - 07/May/07 05:25 AM
I see blob_id 0:0 in record. Also i see that NULL flag is not set for this field.

The only reason i can imagine for this is as follow:
user have nullable field initially, insert record with NULL blob, set NOT NULL flag manually and updated record leaving NULL in blob

This just a guess as i saw 'corrupted' db only (not talking with user about it) and real case was a bit complex ;)

Martijn Tonies added a comment - 08/May/07 03:50 AM
Ah, so you mean that on the data page, for the field value, the NULL flag is not set, while it is set in the metadata ( by using a direct system table update? )

Vlad Khorsun added a comment - 08/May/07 04:37 AM

And i wrong that it can be done only by direct modifications in system tables ;)
We can add NOT NULL constraint via DDL of course.
We can't drop this constraint but this is another story ;)

Pavel Cisar added a comment - 24/Jul/07 08:03 AM
As there is no clear and definitive test case (so the test was not created), I can only judge by changes made to the source, and it appears ok for both branches.