Bug #44095 Falcon fails to match rows when a big bigint constant is used in an UPDATE

• Submitted: 5 Apr 2009 13:00
• Modified: 26 May 2010 17:52
• Reporter: Philip Stoev
• Status: Unsupported
• Category: MySQL Server: Falcon storage engine
• Severity: S3 (Non-critical)
• Version: 6.0-falcon-team
• OS: Any
• Assigned to: Lars-Erik Bjørk
• CPU Architecture: Any
• Tags: F_ENCODING

[5 Apr 2009 13:00] Philip Stoev

Description:
If a big bigint value is used in an UPDATE statement, Falcon will fail to match any rows. Smaller values work as expected.

The same condition, when used in a SELECT query, matches the desired rows.

How to repeat:
--source include/have_falcon.inc
DROP TABLE table10;
CREATE TABLE `table10` (`tinyint_key` tinyint,
	`tinyint` tinyint,
        key (`tinyint_key` )
) ENGINE=Falcon;

INSERT IGNORE INTO table10 VALUES  ('127', '127');

# This query will fail to match any rows
UPDATE `table10` SET `tinyint` = 3 WHERE `tinyint_key` < 9858196575757533184;
SELECT * FROM table10;

# This query will correctly match the desired row
UPDATE `table10` SET `tinyint` = 3 WHERE `tinyint_key` < 985819657575753318;
SELECT * FROM table10;

[7 Apr 2009 22:08] Ann Harrison

Note that the failure occurs only with tinyint fields.  Integer and 
smallint get the right answer.  The literal is 19 digits.  18 digit
literals work with tinyint keys.