List:Internals« Previous MessageNext Message »
From:Kristian Nielsen Date:October 15 2009 9:34pm
Subject:DECIMAL broken in information_schema by patch for Bug#45261
View as plain text  
I found a problem introduced in MySQL 5.1.39 by the patch for Bug#45261.

The bzr revision is this:


To see the problem, apply a patch like this:

=== modified file 'sql/'
--- sql/	2009-07-16 12:43:17 +0000
+++ sql/	2009-10-15 21:19:44 +0000
@@ -34,7 +34,7 @@
 /** two vals encoded: (dec*100)+len */
 #define MAX_QUERY_LENGTH 300

Then run the query SHOW CREATE TABLE information_schema.PROFILING:

  `DURATION` decimal(9,6) NOT NULL DEFAULT '0.000000',

In fact, no matter what precision is specified in for the
table, the type is always decimal(9,6)!

Specifically, the problem is with this part of the patch:

=== modified file 'sql/'
--- sql/	2009-07-19 12:49:40 +0000
+++ sql/	2009-08-24 19:47:08 +0000
@@ -4902,9 +4911,7 @@ Field *Item::tmp_table_field_from_field_type
   switch (field_type()) {
-    field= new Field_new_decimal((uchar*) 0, max_length, null_ptr, 0,
-                                 Field::NONE, name, decimals, 0,
-                                 unsigned_flag);
+    field= Field_new_decimal::new_decimal_field(this);
     field= new Field_tiny((uchar*) 0, max_length, null_ptr, 0, Field::NONE,

This creates a Field from an Item, and is used when getting the Field
describing a DECIMAL column of an information_schema table.

Note that the old code uses item->max_length to set the precision, so the
precision will be set from the _type_ (metadata) of the Item.

But the new code uses the new method Field_new_decimal::new_decimal_field()
from the patch. This method sets the precision of the Field from the _value_
of the item.

This causes the bug. In create_schema_table(), we call create_tmp_table() with
a list of items. This call passes the items one by one to
create_tmp_field_for_schema(), which just returns
item->tmp_table_field_from_field_type(). With the above change, the field type
becomes set from the value of the item not the type, causing the wrong

Any idea how to fix this regression?

(Found this since it breaks the Percona microsec_process patch, which uses a
DECIMAL(22,3) type column in information_schema.)

 - Kristian.
DECIMAL broken in information_schema by patch for Bug#45261Kristian Nielsen15 Oct
  • Re: DECIMAL broken in information_schema by patch for Bug#45261Davi Arnaut2 Nov
    • Re: DECIMAL broken in information_schema by patch for Bug#45261Kristian Nielsen2 Nov