1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-27 13:04:36 +03:00
Commit Graph

20620 Commits

Author SHA1 Message Date
Georgi Kodinov
b3099b51fa merge mysql-5.5->mysql-5.5-security 2012-03-21 14:56:29 +02:00
Joerg Bruehe
a70c8c4b20 Merge the 5.5.22 release build into main 5.5,
conflict in "sql/filesort.cc" solved manually.
2012-03-20 22:27:49 +01:00
Alexander Barkov
f75dbdd160 Bug#13832953 MY_STRNXFRM_UNICODE: ASSERTION `SRC' FAILED. | MY_STRNXFRM_UNICODE/MAKE_SORTKEY
Problem:

Field_set::val_str in case of an empty SET value
returned a String with str_length==0 and Ptr==0,
which is not expected by some pieces of the code.

Fix:
      
Returning an empty string with str_length==0 and Ptr=="",
like Field_enum does.
2012-03-20 09:16:51 +04:00
Jon Olav Hauglid
70207671eb Merge from mysql-5.5 to mysql-5.5-security
Text conflict in sql/share/errmsg-utf8.txt
2012-03-15 12:29:01 +01:00
Jon Olav Hauglid
f901156905 Merge from mysql-5.5 to mysql-5.5-security
Text conflict in sql/filesort.cc
2012-03-15 11:28:29 +01:00
Jon Olav Hauglid
e57cba1035 Merge from mysql-5.5 to mysql-5.5-security
No conflicts
2012-03-15 11:25:53 +01:00
Dmitry Shulga
1a7e7a0f75 This patch fixes the bug#13737343 (formerly known as 64374): XA TRANSACTIONS
AND SAVEPOINT.
      
The bug was introduced by the patch for bug#11766752. This patch sets too
strong condition on XA state for SAVEPOINT statement that disallows its
execution during XA transaction. But since the statement SAVEPOINT doesn't
imply implicit commit we can allow its handling during XA transaction.

The patch explicitly check for transaction state against states XA_NOTR
and XA_ACTIVE for which the handling of statement SAVEPOINT for XA
transaction is allowed.
2012-03-15 15:10:57 +06:00
Mattias Jonsson
aaf0e5d604 merge of bug#1364811 into mysql-5.5 2012-03-14 21:57:15 +01:00
Tor Didriksen
c8f4e2793d Bug#13721076 CRASH WITH TIME TYPE/TIMESTAMP() AND WARNINGS IN SUBQUERY
The table contains one time value: '00:00:32'
This value is converted to timestamp by a subquery.

In convert_constant_item we call (*item)->is_null()
which triggers execution of the Item_singlerow_subselect subquery,
and the string "0000-00-00 00:00:32" is cached
by Item_cache_datetime.
We continue execution and call update_null_value, which calls val_int()
on the cached item, which converts the time value to ((longlong) 32)
Then we continue to do (*item)->save_in_field()
which ends up in Item_cache_datetime::val_str() which fails,
since (32 < 101) in number_to_datetime, and val_str() returns NULL.

Item_singlerow_subselect::val_str isnt prepared for this:
if exec() succeeds, and return !null_value, then val_str()
*must* succeed.

Solution: refuse to cache strings like "0000-00-00 00:00:32"
in Item_cache_datetime::cache_value, and return NULL instead.

This is similar to the solution for 
Bug#11766860 - 60085: CRASH IN ITEM::SAVE_IN_FIELD() WITH TIME DATA TYPE

This patch is for 5.5 only.
The issue is not present after WL#946, since a time value
will be converted to a proper timestamp, with the current date
rather than "0000-00-00"
2012-03-14 13:25:14 +01:00
Tor Didriksen
cfea7c7dfc Bug#13832772 ASSERTION `THD->IS_ERROR() || KILL_ERRNO'
We are trying to sort a lot of text/blob fields, 
so the buffer is indeed too small.
Memory available = thd->variables.sortbuff_size = 262144
min_sort_memory = param.sort_length*MERGEBUFF2 = 292245
So the decision to abort the query is correct.

filesort() calls my_error(), the error is reported.
But, since we have DELETE IGNORE ... the error is converted to a warning by
THD::raise_condition

filesort currently expects an error to be recorded in the THD diagnostics
area.
If we lift this restriction (remove the assert) we end up in the familiar
void Protocol::end_statement()
  default:
    DBUG_ASSERT(0);

The solution seems to be to call my_error(ME_FATALERROR) in filesort,
so that the error is propagated as an error rather than a warning.
2012-03-14 12:28:41 +01:00
Chaithra Gopalareddy
d93559f9ff Bug#12626844 : WE ARE NOT CHECKING VIEW TABLE NAMES
ENOUGH - CONCAT() HACKS. ALSO WRONG
               ERROR MESSAGE WHILE TRYING TO CREATE
               A VIEW ON A NON EXISTING DATABASE

PROBLEM:
The first part of the problem is concluded as not a
bug, as 'concat' is not a reserved word and it is
completely valid to create a view with the name
'concat'.

The second issue is, while trying to create a view on
a non existing database, we are not giving a proper error
message.

FIX:
We have added a check for the database existence while
trying to create a view. This check would give an error
as 'unknown database' when the database does not exist.

This patch is a backport of the patch for Bug#13601606
2012-03-14 06:27:03 +05:30
Norvald H. Ryeng
bedf97c93a Merge 5.1 => 5.5. 2012-03-12 09:24:59 +01:00
Norvald H. Ryeng
2e72df370b Bug#13031606 VALUES() IN A SELECT STATEMENT CRASHES SERVER
Problem: Grouping results by VALUES(alias for string literal) causes
the server to crash.

Item_insert_values is not constructed to handle other types of
arguments than field and reference to field. In this case, the
argument is an Item_string, and this causes
Item_insert_values::fix_fields() to crash.

Fix: Issue an error message when the argument to Item_insert_values is
not a field or a reference to a field.

This is slightly in breach with documentation, which states that
VALUES should return NULL, but the error message is only issued in
cases where the server otherwise would crash, so there is no change in
behavior for queries that already work. Future versions will restrict
syntax so that using VALUES in this way is illegal.
2012-03-12 08:56:56 +01:00
Dmitry Lenev
c7a6ee1964 Merged fix for a test case into 5.5 tree. 2012-03-11 16:11:08 +04:00
Dmitry Lenev
745b849455 Fixed test case for bug #13105873 "valgrind warning:possible
crash in foreign key handling on subsequent create table if
not exists".

Do not leave current database unassigned after the end of
the test case.
2012-03-11 16:05:42 +04:00
Georgi Kodinov
35d865f2fe Bug #12408412: GROUP_CONCAT + ORDER BY + INPUT/OUTPUT SAME
USER VARIABLE = CRASH

Moved the preparation of the variables that receive the output from 
SELECT INTO from execution time (JOIN:execute) to compile time 
(JOIN::prepare). This ensures that if the same variable is used in the
SELECT part of SELECT INTO it will be properly marked as non-const
for this query.
Test case added.
Used proper fast iterator.
2012-03-09 15:04:49 +02:00
Georgi Kodinov
2a91c8de82 merge mysql-5.5->mysql-5.5-security 2012-03-08 17:19:54 +02:00
Georgi Kodinov
8232d9a6ee merge mysql-5.1->mysql-5.1-security 2012-03-08 17:16:53 +02:00
Ramil Kalimullin
bbcce1cbc5 Auto-merge from mysql-5.1-security. 2012-03-06 15:17:06 +04:00
Ramil Kalimullin
930a5b918d BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN
GEOMETRY FUNCTION ARGUMENTS

Fixed --ps-protocol gis test failure.
2012-03-06 15:13:56 +04:00
Ramil Kalimullin
036a1e842a Auto-merge from mysql-5.1-security. 2012-03-05 22:36:56 +04:00
Ramil Kalimullin
97c429f65b BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS
A defect in the subquery substitution code may lead to a server crash:
setting substitution's name should be followed by setting its length
(to keep them in sync).
2012-03-05 22:15:23 +04:00
Ramil Kalimullin
44d88da575 Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS
Problem:      
lack of incoming geometry data validation may 
lead to a server crash when ISCLOSED() function called.

Solution:
necessary incoming data check added.
2012-03-05 21:58:07 +04:00
Mattias Jonsson
cef28c88a3 merge from mysql-5.1 2012-02-29 21:18:50 +01:00
Mattias Jonsson
bd5f062f92 merge into mysql-5.1 2012-02-29 20:51:38 +01:00
Praveenkumar Hulakund
892760d9ee Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
Analysis:
========================
sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
instead of escape character in a string literal then sql_mode can be set to 
"NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
character like any other. 

SQL_MODE set applies to the current client session. And while creating the stored 
procedure, MySQL stores the current sql_mode and always executes the stored 
procedure in sql_mode stored with the Procedure, regardless of the server SQL 
mode in effect when the routine is invoked.  

In the scenario (for which bug is reported), the routine is created with 
sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
is "" (NOT SET) by executing statement "call testp('Axel\'s')".
Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
is considered as escape character and column "a" (of table "t1") values are 
updated with "Axel's". The binary log generated for above update operation is as below,

  set sql_mode=XXXXXX (for no_backslash_escapes)
  update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');

While logging stored procedure statements, the local variables (params) used in
statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
(http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)

On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
is also logged in. So that at slave this sql_mode is set before executing the statements
of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
and parsing reported error for "'" (as we have only one "'" no backslash). 

At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
But above error reported while writing bin log, "'" (of Axel's) is escaped with
"\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
while writing NAME_CONST for string variable(param, local variable) in bin log 
irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
that logging string parameter does not take into account sql_mode value.

Fix:
========================
So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
(n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
escape such characters while writing NAME_CONST for string variables in bin 
log. 
And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
represented as ''.
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
ways to include quote characters within a string: )
2012-02-29 14:52:08 +05:30
Praveenkumar Hulakund
9af695fb45 Bug#12601974 - STORED PROCEDURE SQL_MODE=NO_BACKSLASH_ESCAPES IGNORED AND BREAKS REPLICATION
Analysis:
========================
sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input,
instead of escape character in a string literal then sql_mode can be set to 
"NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary 
character like any other. 

SQL_MODE set applies to the current client session. And while creating the stored 
procedure, MySQL stores the current sql_mode and always executes the stored 
procedure in sql_mode stored with the Procedure, regardless of the server SQL 
mode in effect when the routine is invoked.  

In the scenario (for which bug is reported), the routine is created with 
sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode
is "" (NOT SET) by executing statement "call testp('Axel\'s')".
Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function)
is considered as escape character and column "a" (of table "t1") values are 
updated with "Axel's". The binary log generated for above update operation is as below,

  set sql_mode=XXXXXX (for no_backslash_escapes)
  update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci');

While logging stored procedure statements, the local variables (params) used in
statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) 
(http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const)

On slave, these logs are applied. NAME_CONST is parsed to get the variable and its
value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode
is also logged in. So that at slave this sql_mode is set before executing the statements
of routine.  So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while
parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character
and parsing reported error for "'" (as we have only one "'" no backslash). 

At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES".
But above error reported while writing bin log, "'" (of Axel's) is escaped with
"\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped
while writing NAME_CONST for string variable(param, local variable) in bin log 
Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is 
that logging string parameter does not take into account sql_mode value.

Fix:
========================
So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping  characters as 
(n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to
escape such characters while writing NAME_CONST for string variables in bin 
log. 
And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is
represented as ''.
http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several 
ways to include quote characters within a string: )
2012-02-29 12:23:15 +05:30
Praveenkumar Hulakund
a0238152c7 Merge from 5.1 to 5.5 2012-02-29 14:15:15 +05:30
Chaithra Gopalareddy
5e8eb57168 Merge from 5.1 to 5.5 2012-02-24 11:55:28 +05:30
Chaithra Gopalareddy
df8827d0e6 Bug#13012483:EXPLAIN EXTENDED, PREPARED STATEMENT, CRASH IN
CHECK_SIMPLE_EQUALITY

PROBLEM:
Crash in "check_simple_equality" when using a subquery with "IN" and
"ALL" in prepare.

ANALYSIS:
Crash can be reproduced using a simplified query like this one:
prepare s from "select 1 from g1 where 1 < all (
                select @:=(1 in (select 1 from g1)) from g1)";

This bug is currently present only on 5.5.and 5.1. Its fixed as part
of work log(#1110) in 5.6. We are taking one change to fix this
in 5.5 and 5.1.

Problem seems to be present because we are trying to evaluate "is_null"
on an argument which is part of a subquery
(In Item_is_not_null_test::update_used_tables()).
But the condition to evaluate is only when we do not have a sub query
present, which means to say that "with_subselect" is not set.
With respect to the above query, we create an object of type
"Item_in_optimizer" which by definition is always associated with a
subquery. While in 5.6 we set "with_subselect" to true for
"Item_in_optimizer" object, we do not do the same in 5.5. This results in
the evaluation for "is_null" resulting in a coredump.
So, we are now setting "with_subselect" to true for "Item_in_optimizer"
in 5.1 and 5.5.
2012-02-24 11:53:36 +05:30
Mattias Jonsson
42282c10ce Bug#13694811: THE OPTIMIZER WRONGLY USES THE FIRST INNODB
PARTITION STATISTICS

Problem was the fix for bug#11756867; It always used the first
partitions, and stopped after it checked 10 [sub]partitions.
(or until it found a partition which would contain a match).

This results in bad statistics for tables where the first 10 partitions
don't represent the majority of the data (like when the first 10
partitions only contained a few rows in total).

The solution was to take statisics from the partitions containing
the most rows instead:

Added an array of partition ids which is sorted by number of records
in descending order.

this array is used in records_in_range to cover as many records as
possible in as few calls as possible.

Also changed the limit of how many partitions to use for the statistics
from a static max of 10 partitions, into a dynamic model:
Maximum number of partitions is now log2(total number of partitions)
taken from the ordered array.
It will continue calling partitions records_in_range until it has 
checked:
(total rows in matching partitions) * (maximum number of partitions)
/ (number of used partitions)

Also reverted the changes for ha_partition::scan_time() and
ha_partition::estimate_rows_upper_bound() to before
the fix of  bug#11756867. Since they are not as slow as
records_in_range.
2012-02-22 23:13:36 +01:00
Tor Didriksen
309d428872 Merge 5.1-security => 5.5-security 2012-02-22 11:20:52 +01:00
Tor Didriksen
067f83e642 Bug#13519724 63793: CRASH IN DTCOLLATION::SET(DTCOLLATION &SET)
Backport of fix for:
Bug#53236 Segfault in DTCollation::set(DTCollation&)
2012-02-22 11:17:50 +01:00
Mattias Jonsson
7e21bee031 Bug#11761296: 53775: QUERY ON PARTITIONED TABLE RETURNS CACHED
RESULT FROM PREVIOUS TRANSACTION

The current Query Cache API is not fully compatible with
the partitioning engine.

There is no good way to implement support for QC due to:
1) a static callback for ha_partition would need to have access
to all partition names and call the underlying callback for each
[sub]partition with the correct name.
2) pruning would be impossible, even if one used the ulonglong
engine_data due to if engine_data is changed, the table is
invalidated by the QC.

So the only viable solution to avoid incorrect data is to not allow
caching of queries using partitioned tables.

(There are some extra changes, due to removal of \r as line break)
2012-02-20 22:59:11 +01:00
Georgi Kodinov
4ad619f7ee merged mysql-5.5->mysql-5.5-security 2012-02-17 11:55:36 +02:00
Tor Didriksen
8e5d9991d1 Bug#13633383 63183: SMALL SORT_BUFFER_SIZE CRASH IN MERGE_BUFFERS
This patch is a backport of some of the cleanups/refactorings that were done
as part of WL#1393 Optimizing filesort with small limit.
2012-02-14 08:11:28 +01:00
Rohit Kalhans
0a53dd8eae fixing test failure on pb2. 2012-02-13 15:37:50 +05:30
Rohit Kalhans
b836b02fc9 BUG#11758263: Modification of indentation in the added code.
Fixed a typo in the comment.
              Fixing test cases which were previouslyno throwing  due
              disable warnings macro.
2012-02-13 14:12:13 +05:30
Rohit Kalhans
17eea52954 Followup patch for bug#11758263. 2012-02-10 01:43:47 +05:30
Rohit Kalhans
4f7e4c9d1b BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE
Problem: Statements that write to tables with auto_increment columns
         based on the selection from another table, may lead to master
         and slave going out of sync, as the order in which the rows
         are retrieved from the table may differ on master and slave.
            
Solution: We mark writing to a table with auto_increment table
          based on the rows selected from another table as unsafe. This
          will cause the execution of such statements to throw a warning
          and forces the statement to be logged in ROW if the logging
          format is mixed. 
            
Changes:
       1. All the statements that writes to a table with auto_increment 
          column(s) based on the rows fetched from another table, will now
          be unsafe.
       2. CREATE TABLE with SELECT will now be unsafe.
2012-02-09 23:28:33 +05:30
Rohit Kalhans
9153fddf58 Backout the patch for bug#11758263. 2012-02-08 12:10:55 +05:30
Rohit Kalhans
6df5a61d2e BUG#11758263 50440: MARK UNORDERED UPDATE WITH AUTOINC UNSAFE
Problem: Statements that write to tables with auto_increment columns
      based on the selection from another table, may lead to master
      and slave going out of sync, as the order in which the rows
      are retrived from the table may differ on master and slave.
      
      Solution: We mark writing to a table with auto_increment table
      as unsafe. This will cause the execution of such statements to
      throw a warning and forces the statement to be logged in ROW if
      the logging format is mixed. 
      
      Changes: 
      1. All the statements that writes to a table with auto_increment 
      column(s) based on the rows fetched from another table, will now
      be unsafe.
      2. CREATE TABLE with SELECT will now be unsafe.
2012-02-08 00:33:08 +05:30
Martin Hansson
73bd3713af Merge of fix for Bug#11765810. 2012-02-07 17:32:04 +01:00
Martin Hansson
34cd261aae Bug #11765810 58813: SERVER THREAD HANGS WHEN JOIN + WHERE + GROUP BY
IS EXECUTED TWICE FROM P

This bug is a duplicate of bug 12567331, which was pushed to the
optimizer backporting tree on 2011-06-11. This is just a back-port of
the fix. Both test cases are included as they differ somewhat.
2012-02-07 14:16:09 +01:00
Georgi Kodinov
1bd0fe7bb8 merge mysql-5.5->mysql-5.5-security 2012-02-06 18:26:36 +02:00
Georgi Kodinov
145043fd69 merged mysql-5.1->mysql-5.1-security 2012-02-06 18:24:51 +02:00
Mattias Jonsson
98d3ef960d Bug#13593865 - 64037: CRASH IN HA_PARTITION::CREATE_HANDLERS ON
ALTER TABLE AFTER DROP PARTITION
Bug#13608188 - 64038: CRASH IN HANDLER::HA_THD ON ALTER TABLE AFTER
                      REPAIR NON-EXISTING PARTITION

Backport of bug#13357766 from -trunk to -5.5.

The state of some partitions was not reset on failure, leading
to invalid states of partitions in consequent statements.

Fixed by reverting back to original state for all partitions
if not all partition names was resolved.

Also adding extra security by forcing tables to be reopened
in case of error in mysql_alter_table.

(There is also removal of \r at the end of some lines.)
2012-02-02 12:47:17 +01:00
Ashish Agarwal
5068aec9c1 BUG#11756869: Merge from mysql-5.1 to mysql-5.5 2012-02-02 14:25:43 +05:30
Ashish Agarwal
adf79bc12f BUG#11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN
CASES RESETS DATA POINTER TO SMAL

ISSUE: Myisamchk doing sort recover
       on a table reduces data_file_length.
       Maximum size of data file decreases,
       lesser number of rows are stored.

SOLUTION: Size of data_file_length is
          fixed to the original length.
2012-02-02 14:19:38 +05:30
Ashish Agarwal
bec3694b37 BUG#11756869 - 48848: MYISAMCHK DOING SORT RECOVER IN CERTAIN
CASES RESETS DATA POINTER TO SMAL

ISSUE: Myisamchk doing sort recover
       on a table reduces data_file_length.
       Maximum size of data file decreases,
       lesser number of rows are stored.

SOLUTION: Size of data_file_length is
          fixed to the original length.
2012-02-01 11:19:53 +05:30