Commit graph

1219 commits

Author SHA1 Message Date
Konstantin Osipov
4db335dcee Backport of:
----------------------------------------------------------
revno: 2630.22.8
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-runtime
timestamp: Sun 2008-08-10 18:49:52 +0400
message:
  Get rid of typedef struct for the most commonly used types:
  TABLE, TABLE_SHARE, LEX. This simplifies use of tags
  and forward declarations.
2009-10-14 15:14:58 +04:00
Alexander Nozdrin
c30d924dd5 Manual merge from mysql-trunk-merge. 2009-10-14 12:25:39 +04:00
Alexander Nozdrin
ca08f10ccd Manual merge from mysql-trunk-merge. 2009-10-14 12:25:39 +04:00
Tatiana A. Nurnberg
2fc28dd688 manual merge of Bug#43508 2009-10-09 23:57:43 +02:00
Tatiana A. Nurnberg
bab4889fbb manual merge of Bug#43508 2009-10-09 23:57:43 +02:00
Davi Arnaut
8d3d35ea57 Bug#45567: Fast ALTER TABLE broken for enum and set
The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.

The cause was twofold: adding a enumeration or set members to the 
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.

The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.

mysql-test/r/alter_table.result:
  Add test case result for Bug#45567
mysql-test/t/alter_table.test:
  Add test case for Bug#45567
sql/field.cc:
  Check whether two fields can be considered 'equal' for table
  alteration purposes. Fields are equal if they retain the same
  pack length and if new members are added to the end of the list.
sql/field.h:
  Add comment and remove method.
2009-09-29 07:58:42 -03:00
Davi Arnaut
fc3740368a Bug#45567: Fast ALTER TABLE broken for enum and set
The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.

The cause was twofold: adding a enumeration or set members to the 
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.

The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.
2009-09-29 07:58:42 -03:00
Georgi Kodinov
2118bd104c Ported WL#3220 to mysql-next-mr. 2009-09-28 10:21:25 +03:00
Georgi Kodinov
7aa8cd7a11 Ported WL#3220 to mysql-next-mr. 2009-09-28 10:21:25 +03:00
Mats Kindahl
d47710c8dc WL#5016: Fix header file include guards
Adding header include file guards to files that are missing such.
2009-09-23 23:32:31 +02:00
Mats Kindahl
4ad8ef0602 WL#5016: Fix header file include guards
Adding header include file guards to files that are missing such.
2009-09-23 23:32:31 +02:00
Davi Arnaut
fc39459504 Bug#45261: Crash, stored procedure + decimal
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.

The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.

This patch borrows code and ideas from Martin Hansson's patch.

mysql-test/r/type_newdecimal.result:
  Add test case result for Bug#45261. Also, update test case to
  reflect that an additive operation increases the precision of
  the resulting type by 1.
mysql-test/t/type_newdecimal.test:
  Add test case for Bug#45261
sql/field.cc:
  Added DBUG_ASSERT to ensure object's invariant is maintained.
  Implement method to create a field to hold a decimal value
  from an item.
sql/field.h:
  Explain member variable. Add method to create a new decimal field.
sql/item.cc:
  The precision should only be capped when storing the value
  on a table. Also, this makes it impossible to calculate the
  integer part if Item::decimals (the scale) is larger than the
  precision.
sql/item.h:
  Simplify calculation of integer part.
sql/item_cmpfunc.cc:
  Do not limit the precision. It will be capped later.
sql/item_func.cc:
  Use new method for allocating a new decimal field.
  Add a specialized method for retrieving the precision
  of a user variable item.
sql/item_func.h:
  Add method to return the precision of a user variable.
sql/item_sum.cc:
  Use new method for allocating a new decimal field.
sql/my_decimal.h:
  The integer part could be improperly calculated for a decimal
  with 31 digits in the fractional part.
sql/sql_select.cc:
  Use new method which truncates the integer or decimal parts
  as needed.
2009-08-24 16:47:08 -03:00
Davi Arnaut
31afccc407 Bug#45261: Crash, stored procedure + decimal
The problem was that creating a DECIMAL column from a decimal
value could lead to a failed assertion as decimal values can
have a higher precision than those attached to a table. The
assert could be triggered by creating a table from a decimal
with a large (> 30) scale. Also, there was a problem in
calculating the number of digits in the integral and fractional
parts if both exceeded the maximum number of digits permitted
by the new decimal type.

The solution is to ensure that truncation procedure is executed
when deducing a DECIMAL column from a decimal value of higher
precision. If the integer part is equal to or bigger than the
maximum precision for the DECIMAL type (65), the integer part
is truncated to fit and the fractional becomes zero. Otherwise,
the fractional part is truncated to fit into the space left
after the integer part is copied.

This patch borrows code and ideas from Martin Hansson's patch.
2009-08-24 16:47:08 -03:00
Tatiana A. Nurnberg
74deaae946 Bug#43508: Renaming timestamp or date column triggers table copy
Altering a table to update a column with types DATE or TIMESTAMP
would incorrectly be seen as a significant change that necessitates
a slow copy+rename operation instead of a fast update.

There were two problems:

The character set is magically set for TIMESTAMP to be "binary",
but that was done too deep in field use code for ALTER TABLE to
know of it.  Now, put that in the constructor for Field_timestamp.

Also, when we set the character set for the new replacement/
comparison field, also raise the "binary" field flag that tells us
we should compare it exactly.  That is necessary to match the old
stored definition.

Next is the problem that the default length for TIMESTAMP and DATE
fields is different than the length read from the .frm .  The
compressed size is written to the file, but the human-readable,
part-delimited length is used as default length.  IIRC, for
timestamp it was 19!=14, and for date it was 8!=10.  Length
mismatch causes a table copy.

Also, clean up a place where a comparison function alters one of its
parameters and replace it with an assertion of the condition it
mutates.
2009-06-24 13:02:20 +02:00
Tatiana A. Nurnberg
d94797e8b3 Bug#43508: Renaming timestamp or date column triggers table copy
Altering a table to update a column with types DATE or TIMESTAMP
would incorrectly be seen as a significant change that necessitates
a slow copy+rename operation instead of a fast update.

There were two problems:

The character set is magically set for TIMESTAMP to be "binary",
but that was done too deep in field use code for ALTER TABLE to
know of it.  Now, put that in the constructor for Field_timestamp.

Also, when we set the character set for the new replacement/
comparison field, also raise the "binary" field flag that tells us
we should compare it exactly.  That is necessary to match the old
stored definition.

Next is the problem that the default length for TIMESTAMP and DATE
fields is different than the length read from the .frm .  The
compressed size is written to the file, but the human-readable,
part-delimited length is used as default length.  IIRC, for
timestamp it was 19!=14, and for date it was 8!=10.  Length
mismatch causes a table copy.

Also, clean up a place where a comparison function alters one of its
parameters and replace it with an assertion of the condition it
mutates.
2009-06-24 13:02:20 +02:00
Staale Smedseng
a073ee45c2 Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
      
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number 
of the warnings, predominantly "suggest using parentheses 
around && in ||", and empty for and while bodies.
2009-06-09 18:11:21 +02:00
Staale Smedseng
dae006c17f Bug #43414 Parenthesis (and other) warnings compiling MySQL
with gcc 4.3.2
      
Compiling MySQL with gcc 4.3.2 and later produces a number of 
warnings, many of which are new with the recent compiler
versions.
      
This bug will be resolved in more than one patch to limit the
size of changesets. This is the first patch, fixing a number 
of the warnings, predominantly "suggest using parentheses 
around && in ||", and empty for and while bodies.
2009-06-09 18:11:21 +02:00
Michael Widenius
a8fdaa6f2c Merge with base MySQL 5.1
Contains fixes for test cases
Changed release tag to beta

configure.in:
  change release tag to beta
2009-02-15 12:58:34 +02:00
Michael Widenius
bd4e65515f Fixed compiler warnings found by gcc 4.3.2
- Added braces around expressions with &&, ||, & and |
- Added empty line before ; for empty while and for loops
- Added () around if with assignments
- Removed const before function returning simple type

Changed BUILD scripts to not build with NDB 


BUILD/SETUP.sh:
  By default, don't build ndb with --max in Maria tree.
  NDB is not kept up to date anyway in 5.1
client/mysql.cc:
  Added braces around && to get rid of compiler warnings
sql/event_db_repository.cc:
  Added braces around && to get rid of compiler warnings
sql/events.cc:
  Added braces around && to get rid of compiler warnings
sql/field.cc:
  Added braces around && to get rid of compiler warnings
  Fixed for loops
sql/field.h:
  Added braces around & to get rid of compiler warnings
sql/field_conv.cc:
  Added braces around && to get rid of compiler warnings
  Fixed bug when copying between DATETIME fields and strict dates are used
  Removed not needeed else
sql/gstream.cc:
  Added braces around && to get rid of compiler warnings
sql/ha_ndbcluster.cc:
  Added braces around && to get rid of compiler warnings
  Added {} to get rid of compiler warnings
sql/handler.cc:
  Added braces around && to get rid of compiler warnings
sql/item.cc:
  Added braces around && to get rid of compiler warnings
sql/item_cmpfunc.cc:
  Added braces around && to get rid of compiler warnings
  Removed some not needed space
sql/item_func.cc:
  Added braces around && to get rid of compiler warnings
sql/item_strfunc.cc:
  Added braces around && to get rid of compiler warnings
sql/item_subselect.cc:
  Added braces around && to get rid of compiler warnings
sql/item_sum.cc:
  Added braces around && to get rid of compiler warnings
sql/item_timefunc.cc:
  Added braces around && to get rid of compiler warnings
sql/item_xmlfunc.cc:
  Added empty line before ; for empty while and for loops
sql/log.cc:
  Added braces around && to get rid of compiler warnings
sql/log_event.cc:
  Added braces around && to get rid of compiler warnings
  Removed not needed else
sql/log_event_old.cc:
  Added braces around && to get rid of compiler warnings
sql/opt_range.cc:
  Added braces around && to get rid of compiler warnings
sql/opt_sum.cc:
  Added braces around && to get rid of compiler warnings
sql/set_var.cc:
  Added empty line before ; for empty while and for loops
  Added () around if with assignments
sql/slave.cc:
  Added braces around && to get rid of compiler warnings
  Added empty line before ; for empty while and for loops
sql/spatial.h:
  Added braces around && to get rid of compiler warnings
sql/sql_acl.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_analyse.cc:
  Added empty line before ; for empty while and for loops
sql/sql_base.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_connect.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_db.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_delete.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_help.cc:
  Added empty line before ; for empty while and for loops
sql/sql_insert.cc:
  Added braces around && to get rid of compiler warnings
  Added () around if with assignments
sql/sql_lex.cc:
  Cast char array references to uchar; Fixed wrong array referencing when using characters > ASCII 128 in SQL statments
  Added empty line before ; for empty while and for loops
  Trivial indent fixes
  Added braces around && to get rid of compiler warnings
sql/sql_load.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_parse.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_partition.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_plugin.cc:
  Fixed bug in detecing if option variable should be readonly
  Added empty line before ; for empty while and for loops
sql/sql_prepare.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_select.cc:
  Added braces around && to get rid of compiler warnings
  Added () around if with assignments
  Added empty line before ; for empty while and for loops
sql/sql_show.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_table.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_trigger.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_update.cc:
  Added braces around && to get rid of compiler warnings
sql/sql_yacc.yy:
  Added braces around && to get rid of compiler warnings
sql/table.cc:
  Added braces around && to get rid of compiler warnings
sql/table.h:
  Added braces around && to get rid of compiler warnings
sql/time.cc:
  Added braces around && to get rid of compiler warnings
sql/tztime.cc:
  Added braces around && to get rid of compiler warnings
sql/uniques.cc:
  Added braces around && to get rid of compiler warnings
storage/federated/ha_federated.cc:
  Fixed bug in testing of variable to ha_info() (Not critical)
storage/heap/ha_heap.cc:
  Added braces around && to get rid of compiler warnings
storage/maria/ha_maria.cc:
  Fixed bug: Mark that maria_log_dir_path is readonly
  Added braces around && to get rid of compiler warnings
storage/ndb/include/ndbapi/NdbEventOperation.hpp:
  Removed const before function returning simple type
storage/ndb/include/ndbapi/NdbOperation.hpp:
  Removed const before function returning simple type
storage/ndb/src/ndbapi/Ndb.cpp:
  Added empty line before ; for empty while and for loops
storage/ndb/src/ndbapi/NdbEventOperation.cpp:
  Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbEventOperationImpl.cpp:
  Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbEventOperationImpl.hpp:
  Removed const before function returning simple type
storage/ndb/src/ndbapi/NdbRecAttr.cpp:
  Added empty line before ; for empty while and for loops
storage/ndb/src/ndbapi/TransporterFacade.hpp:
  Added braces around && to get rid of compiler warnings
2009-01-31 23:22:44 +02:00
Georgi Kodinov
f97ef7a40e merged 5.1-main -> 5.1-bugteam 2009-01-05 18:10:20 +02:00
Georgi Kodinov
8c25823f94 merged 5.1-main -> 5.1-bugteam 2009-01-05 18:10:20 +02:00
Davi Arnaut
3ce026ec2f Fix warnings and bug spotted by gcc-4.3.
Related to operator precedence and associativity.
Make the expressions as explicit as possible.

sql/field.h:
  Silence gcc-4.3 warning: be more explicit.
sql/item.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/item_sum.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/log_event.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/spatial.h:
  Silence gcc-4.3 warning: be more explicit.
sql/sql_lex.cc:
  Silence gcc-4.3 warning: be more explicit.
sql/table.h:
  Silence gcc-4.3 warning: be more explicit.
storage/federated/ha_federated.cc:
  Fix operator precedence bug.
storage/heap/ha_heap.cc:
  Silence gcc-4.3 warning: be more explicit.
2008-12-16 10:12:22 -02:00
Davi Arnaut
4bdb3d87fa Fix warnings and bug spotted by gcc-4.3.
Related to operator precedence and associativity.
Make the expressions as explicit as possible.
2008-12-16 10:12:22 -02:00
Guilhem Bichot
33b194c36e Merge of 5.1-main into 5.1-maria. There were no changes to storage/myisam, or mysql-test/t/*myisam*.
However there were three new tests mysql-test/suite/parts/t/partition*myisam.test, of which I make here
copies for Maria.
2008-11-21 15:21:50 +01:00
Build Team
e85fe79430 Added "Sun Microsystems, Inc." to copyright headers on files modified
since Oct 1st
2008-11-10 21:21:49 +01:00
Build Team
366adeab08 Added "Sun Microsystems, Inc." to copyright headers on files modified
since Oct 1st
2008-11-10 21:21:49 +01:00
Ramil Kalimullin
256f41edfe Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.

Fix: reinsert data altering an enum field if enum values are changed.


mysql-test/r/alter_table.result:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - test result.
mysql-test/t/alter_table.test:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - test case.
sql/field.cc:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - Field_enum::is_equal() introduced, which is called to detect that a field
  is changing by 'ALTER TABLE'.
sql/field.h:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - Field_enum::is_equal() introduced, which is called to detect that a field
  is changing by 'ALTER TABLE'.
2008-10-24 13:00:03 +05:00
Ramil Kalimullin
adf630dcee Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.

Fix: reinsert data altering an enum field if enum values are changed.
2008-10-24 13:00:03 +05:00
Michael Widenius
f47e003e1b Merged 5.1 with maria 5.1 2008-10-10 18:28:41 +03:00
Kristofer Pettersson
153e8e7c07 Merge 5.0-bugteam -> 5.1-bugteam 2008-09-20 16:52:34 +02:00
Kristofer Pettersson
53cf8914e4 Merge 5.0-bugteam -> 5.1-bugteam 2008-09-20 16:52:34 +02:00
Kristofer Pettersson
f0352e346a Bug#38469 invalid memory read and/or crash with utf8 text field, stored procedure, uservar
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
          
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the 
cached value storage was reallocated to provide access for a new 
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.


mysql-test/r/sp.result:
  Added result set
mysql-test/t/sp.test:
  Added test case
sql/field.cc:
  The source and destination address ranges of a character conversion must not overlap or the 'from' address will be invalidated as the temporary value-
  object is re-allocated to fit the new character set.
sql/field.h:
  Added comments
2008-09-20 10:51:03 +02:00
Kristofer Pettersson
18b3eacbc6 Bug#38469 invalid memory read and/or crash with utf8 text field, stored procedure, uservar
A stored procedure involving substrings could crash the server on certain
platforms because of invalid memory reads.
          
During storing the new blob-field value, the cached value's address range
overlapped that of the new field value. This caused problems when the 
cached value storage was reallocated to provide access for a new 
characater set representation. The patch checks the address ranges, and if
they overlap, the new field value is copied to a new storage before it is
converted to the new character set.
2008-09-20 10:51:03 +02:00
Georgi Kodinov
8b0e99fe26 merge 5.0-bugteam -> 5.1-bugteam 2008-08-28 12:54:50 +03:00
Georgi Kodinov
4c318bf6e8 merge 5.0-bugteam -> 5.1-bugteam 2008-08-28 12:54:50 +03:00
Gleb Shchepa
54a59681d6 Bug #37799: SELECT with a BIT column in WHERE clause
returns unexpected result

If:
  1. a table has a not nullable BIT column c1 with a length
     shorter than 8 bits and some additional not nullable
     columns c2 etc, and
  2. the WHERE clause is like: (c1 = constant) AND c2 ...,
the SELECT query returns unexpected result set.


The server stores BIT columns in a tricky way to save disk
space: if column's bit length is not divisible by 8, the
server places reminder bits among the null bits at the start
of a record. The rest bytes are stored in the record itself,
and Field::ptr points to these rest bytes.

However if a bit length of the whole column is less than 8,
there are no remaining bytes, and there is nothing to store in
the record at its regular place. In this case Field::ptr points
to bytes actually occupied by the next column in a record.
If both columns (BIT and the next column) are NOT NULL,
the Field::eq function incorrectly deduces that this is the
same column, so query transformation/equal item elimination
code (see build_equal_items_for_cond) may mix these columns
and damage conditions containing references to them.


mysql-test/r/type_bit.result:
  Added test case for bug #37799.
mysql-test/t/type_bit.test:
  Added test case for bug #37799.
sql/field.h:
  1. The Field::eq function has been modified to take types of
  comparing columns into account to distinguish between BIT and
  not BIT columns referencing the same bytes in a record.
  
  2. Unnecessary type comparison has been removed from the
  Field_bit::eq function (moved to Field::eq).
2008-08-28 02:10:37 +05:00
Gleb Shchepa
2c53f10969 Bug #37799: SELECT with a BIT column in WHERE clause
returns unexpected result

If:
  1. a table has a not nullable BIT column c1 with a length
     shorter than 8 bits and some additional not nullable
     columns c2 etc, and
  2. the WHERE clause is like: (c1 = constant) AND c2 ...,
the SELECT query returns unexpected result set.


The server stores BIT columns in a tricky way to save disk
space: if column's bit length is not divisible by 8, the
server places reminder bits among the null bits at the start
of a record. The rest bytes are stored in the record itself,
and Field::ptr points to these rest bytes.

However if a bit length of the whole column is less than 8,
there are no remaining bytes, and there is nothing to store in
the record at its regular place. In this case Field::ptr points
to bytes actually occupied by the next column in a record.
If both columns (BIT and the next column) are NOT NULL,
the Field::eq function incorrectly deduces that this is the
same column, so query transformation/equal item elimination
code (see build_equal_items_for_cond) may mix these columns
and damage conditions containing references to them.
2008-08-28 02:10:37 +05:00
Marc Alff
7f228cf20e Manual merge of mysql-5.0-bugteam -> mysql-5.1-bugteam
Note: NULL merge of sql/sql_yacc.yy, the fix for bug#38296 will be provided separately for 5.1
2008-08-11 16:44:13 -06:00
Marc Alff
385b4bf7ff Manual merge of mysql-5.0-bugteam -> mysql-5.1-bugteam
Note: NULL merge of sql/sql_yacc.yy, the fix for bug#38296 will be provided separately for 5.1
2008-08-11 16:44:13 -06:00
Marc Alff
e04dfffb59 Bug#38296 (low memory crash with many conditions in a query)
This fix is for 5.0 only : back porting the 6.0 patch manually

The parser code in sql/sql_yacc.yy needs to be more robust to out of
memory conditions, so that when parsing a query fails due to OOM,
the thread gracefully returns an error.

Before this fix, a new/alloc returning NULL could:
- cause a crash, if dereferencing the NULL pointer,
- produce a corrupted parsed tree, containing NULL nodes,
- alter the semantic of a query, by silently dropping token values or nodes

With this fix:
- C++ constructors are *not* executed with a NULL "this" pointer
when operator new fails.
This is achieved by declaring "operator new" with a "throw ()" clause,
so that a failed new gracefully returns NULL on OOM conditions.

- calls to new/alloc are tested for a NULL result,

- The thread diagnostic area is set to an error status when OOM occurs.
This ensures that a request failing in the server properly returns an
ER_OUT_OF_RESOURCES error to the client.

- OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
This prevents causing further crashes when using a partially built parsed
tree in further rules in the parser.

No test scripts are provided, since automating OOM failures is not
instrumented in the server.
Tested under the debugger, to verify that an error in alloc_root cause the
thread to returns gracefully all the way to the client application, with
an ER_OUT_OF_RESOURCES error.
2008-08-11 10:10:00 -06:00
Marc Alff
394691cd90 Bug#38296 (low memory crash with many conditions in a query)
This fix is for 5.0 only : back porting the 6.0 patch manually

The parser code in sql/sql_yacc.yy needs to be more robust to out of
memory conditions, so that when parsing a query fails due to OOM,
the thread gracefully returns an error.

Before this fix, a new/alloc returning NULL could:
- cause a crash, if dereferencing the NULL pointer,
- produce a corrupted parsed tree, containing NULL nodes,
- alter the semantic of a query, by silently dropping token values or nodes

With this fix:
- C++ constructors are *not* executed with a NULL "this" pointer
when operator new fails.
This is achieved by declaring "operator new" with a "throw ()" clause,
so that a failed new gracefully returns NULL on OOM conditions.

- calls to new/alloc are tested for a NULL result,

- The thread diagnostic area is set to an error status when OOM occurs.
This ensures that a request failing in the server properly returns an
ER_OUT_OF_RESOURCES error to the client.

- OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
This prevents causing further crashes when using a partially built parsed
tree in further rules in the parser.

No test scripts are provided, since automating OOM failures is not
instrumented in the server.
Tested under the debugger, to verify that an error in alloc_root cause the
thread to returns gracefully all the way to the client application, with
an ER_OUT_OF_RESOURCES error.
2008-08-11 10:10:00 -06:00
Kristofer Pettersson
548413824b Bug#38002 table_cache consumes too much memory with blobs
Tables in the table definition cache are keeping a cache buffer for blob
fields which can consume a lot of memory.
    
This patch introduces a maximum size threshold for these buffers.


sql/sql_base.cc:
  Added function free_field_buffers_larger_than to reclaim memory from blob
  field buffers too large to be cached.
sql/table.cc:
  Added function free_field_buffers_larger_than
2008-07-24 22:38:44 +02:00
Kristofer Pettersson
5c1f8d1836 Bug#38002 table_cache consumes too much memory with blobs
Tables in the table definition cache are keeping a cache buffer for blob
fields which can consume a lot of memory.
    
This patch introduces a maximum size threshold for these buffers.
2008-07-24 22:38:44 +02:00
Joerg Bruehe
b69b20b2d6 Merge 5.1.26-rc to 5.1-build for further pushing it to the main tree. 2008-07-11 20:51:10 +02:00
Joerg Bruehe
241581fb8d Merge 5.1.26-rc to 5.1-build for further pushing it to the main tree. 2008-07-11 20:51:10 +02:00
Mats Kindahl
711305e2c5 BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.

Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).

Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most 
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this 
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.


mysql-test/extra/rpl_tests/rpl_row_basic.test:
  Adding test cases for replicating UTF-8 fields of lengths
  of 256 or more (bytes).
mysql-test/suite/binlog/r/binlog_base64_flag.result:
  Result file change.
mysql-test/suite/binlog/t/binlog_base64_flag.test:
  Adding tests to trigger check that an error is generated when replicating from a
  5.1.25 server for tables with a CHAR(128) but not when replicating a table with a
  CHAR(63). Although the bug indicates that the limit is 83, we elected to use CHAR(63)
  since 6.0 uses 4-byte UTF-8, and anything exceeding 63 would then cause the test to fail
  when the patch is merged to 6.0.
mysql-test/suite/bugs/combinations:
  Adding combinations file to run all bug reports in all binlog modes (where
  applicable).
mysql-test/suite/bugs/r/rpl_bug37426.result:
  Result file change.
mysql-test/suite/bugs/t/rpl_bug37426.test:
  Added test for reported bug.
mysql-test/suite/rpl/r/rpl_row_basic_2myisam.result:
  Result file change.
mysql-test/suite/rpl/r/rpl_row_basic_3innodb.result:
  Result file change.
sql/field.cc:
  Encoding an extra two bits in the most significant nibble (4 bits)
  of the metadata word. Adding assertions to ensure that no attempt
  is made to use lengths longer than supported.
  
  Extending compatible_field_size() function with an extra parameter
  holding a Relay_log_instace for error reporting.
  
  Field_string::compatible_field_size() now reports an error if field
  size for a CHAR is >255.
sql/field.h:
  Field length is now computed from most significant 4 bits
  of metadata word, or is equal to the row pack length if
  there is no metadata.
  
  Extending compatible_field_size() function with an extra parameter
  holding a Relay_log_instace for error reporting.
sql/rpl_utility.cc:
  Adding relay log parameter to compatible_field_size().
  
  Minor refactoring to eliminate duplicate code.
sql/slave.cc:
  Extending rpl_master_has_bug() with a single-argument predicate function and
  a parameter to the predicate function. The predicate function can be used to
  test for extra conditions for the bug before writing an error message.
sql/slave.h:
  Extending rpl_master_has_bug() with a single-argument predicate function and
  a parameter to the predicate function. The predicate function can be used to
  test for extra conditions for the bug before writing an error message.
  
  Also removing gratuitous default argument.
sql/sql_insert.cc:
  Changing calls to rpl_master_has_bug() to adapt to changed signature.
2008-06-30 22:11:18 +02:00
Mats Kindahl
2a089557a6 BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars
In order to handle CHAR() fields, 8 bits were reserved for
the size of the CHAR field. However, instead of denoting the
number of characters in the field, field_length was used which
denotes the number of bytes in the field.

Since UTF-8 fields can have three bytes per character (and
has been extended to have four bytes per character in 6.0),
an extra two bits have been encoded in the field metadata
work for fields of type Field_string (i.e., CHAR fields).

Since the metadata word is filled, the extra bits have been
encoded in the upper 4 bits of the real type (the most 
significant byte of the metadata word) by computing the
bitwise xor of the extra two bits. Since the upper 4 bits
of the real type always is 1111 for Field_string, this 
means that for fields of length <256, the encoding is
identical to the encoding used in pre-5.1.26 servers, but
for lengths of 256 or more, an unrecognized type is formed,
causing an old slave (that does not handle lengths of 256
or more) to stop.
2008-06-30 22:11:18 +02:00
Gleb Shchepa
c8bc6a5d1b Fixed bug #37076: TIMESTAMP/DATETIME/DATE values are not
replicated correctly between machines with
                  mixed endiannes


mysql-test/extra/rpl_tests/rpl_row_basic.test:
  Added regression test for bug#37076.
mysql-test/suite/rpl/r/rpl_row_basic_2myisam.result:
  Added regression test for bug#37076.
mysql-test/suite/rpl/r/rpl_row_basic_3innodb.result:
  Added regression test for bug#37076.
mysql-test/suite/rpl_ndb/r/rpl_row_basic_7ndb.result:
  Added regression test for bug#37076.
sql/field.h:
  Fixed bug #37076: TIMESTAMP/DATETIME/DATE values are not
                    replicated correctly between machines with
                    mixed endiannes
  
  pack and unpack virtual methods have been overloaded for
  Field_timestamp (TIMESTAMP domain), Field_datetime (DATETIME
  domain) and Field_date (DATE domain) classes to replicate data
  between platforms with different endiannes in a correct way
  like in Field_long and Field_longlong classes.
  
  Common code have been moved to private handle_int32 and 
  handle_int64 private methods.
2008-06-19 18:02:04 +05:00
Gleb Shchepa
954fba4739 Fixed bug #37076: TIMESTAMP/DATETIME/DATE values are not
replicated correctly between machines with
                  mixed endiannes
2008-06-19 18:02:04 +05:00
unknown
ff1588ca83 Merge host.loc:/work/bugs/5.0-bugteam-30059
into  host.loc:/work/bk/5.1-bugteam


mysql-test/r/heap.result:
  Auto merged
mysql-test/r/innodb.result:
  Auto merged
mysql-test/r/myisam.result:
  Auto merged
mysql-test/r/strict.result:
  Auto merged
mysql-test/r/type_binary.result:
  Auto merged
mysql-test/r/warnings.result:
  Auto merged
BitKeeper/deleted/.del-bdb.result:
  Auto merged
sql/field.cc:
  Auto merged
sql/field.h:
  Auto merged
2008-05-13 17:01:02 +05:00