1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-10 04:22:00 +03:00
Commit Graph

20681 Commits

Author SHA1 Message Date
82b115ec16 Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
mysql client displays wrong character-set of server. When a user changes the
charset of a server, mysql client 'status' command displays wrong charset but
the command "SHOW VARIABLES LIKE "%charset%" displayed correct charset results.
The problem is only with the mysql client's 'status' command output.

In mysql client, the method mysql_store_lazy_result() returns 0 for
success and non-zero for failure. The method com_status() was using this method
wrongly. Fixed all such instances according to return value of the method 
mysql_store_lazy_result().

client/mysql.cc:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Fix com_status() method to use mysql_store_lazy_result() properly.
mysql-test/r/bug47671.result:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671
mysql-test/t/bug47671-master.opt:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671
mysql-test/t/bug47671.test:
  Fix for BUG#47671 - wrong character-set after upgrade from 5.1.34 to 5.1.39
  
  Testcase for BUG#47671
2009-11-25 12:25:49 +05:30
9ae245009c auto-merge 2009-11-24 10:22:22 -08:00
8af680218e Auto-merge. 2009-11-24 18:30:21 +03:00
9f638f535e Manual merge of the fix for bug#43668. 2009-11-24 18:26:13 +03:00
edaae7c3e2 merge 2009-11-24 13:27:29 +01:00
9561a29b2f merge of bug#35765 into mysql-next-mr-bugfixing
mysql-test/r/log_tables.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/r/partition.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/r/partition_innodb.result:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated result
mysql-test/t/log_tables.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated test
mysql-test/t/partition.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Added test case
mysql-test/t/partition_innodb.test:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  Updated test
sql/protocol.cc:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  (fix of bug#48939 to avoid test failures on my test build).
sql/sql_yacc.yy:
  Bug #35765  	ALTER TABLE produces wrong error when non-existent storage engine used
  
  if no existing engine was given, don't set HA_CREATE_USED_ENGINE
2009-11-24 12:08:04 +01:00
adb89e98aa Manual merge from the mysql-5.1-bugteam. 2009-11-24 11:31:36 +03:00
a460914482 Manual merge from the mysql-5.1-bugteam. 2009-11-24 11:19:06 +03:00
84c5abbd33 Backport fix for Bug #27884. 2009-11-23 14:38:08 -08:00
206c636ec8 Reviewed patch of QA results for WL#798. 2009-11-23 17:38:42 +01:00
908323304e Automerge. 2009-11-23 13:07:18 +03:00
6780169613 Automerge. 2009-11-23 13:05:35 +03:00
38ed9324be Automerge. 2009-11-23 13:04:17 +03:00
a4bcf99f38 Backport of the fix for bug #33969: Updating a text field via a
left join 

When creating a temporary TEXT/BLOB field from an Item in
Item::make_string_field(), the field's type was unconditionally
set to the one corresponding to the maximum length (i.e.
LONGTEXT/ LONGBLOB). This resulted in problems when exactly the
same TEXT/BLOB is type required in cases like CREATE ... SELECT
or creating internal temporary tables for joins. 

Fixed by calling a different constructor for Field_blob so that
an appropriate type is used depending on the Item's max_length
value.
2009-11-21 20:31:00 +03:00
8c1dfab38d Merged from mysql-next-mr-bugfixing.
Updated the result file for func_math.
2009-11-21 19:46:50 +03:00
c70a9fa1e3 Bug#41726: upgrade from 5.0 to 5.1.30 crashes if you didn't run mysql_upgrade
The problem is that the server could crash when attempting
to access a non-conformant proc system table. One such case
was a crash when invoking stored procedure related statements
on a 5.1 server with a proc system table in the 5.0 format.

The solution is to validate the proc system table format
before attempts to access it are made. If the table is not
in the format that the server expects, a message is written
to the error log and the statement that caused the table to
be accessed fails.

mysql-test/r/sp-destruct.result:
  Add test case result for Bug#41726
mysql-test/t/sp-destruct.test:
  Add test case for Bug#41726
sql/event_db_repository.cc:
  Update code to use new structures.
sql/sp.cc:
  Describe the proc table format and use it to validate when
  opening a instance of the table.
  Add a check to insure that a error message is written to
  the error log only once.
sql/sql_acl.cc:
  Remove unused variable and use new structure.
sql/sql_acl.h:
  Export field definition.
sql/table.cc:
  Accept the field count and definition in a single structure.
sql/table.h:
  Combine the field count and definition in a single structure.
  Transform function into a class in order to support different
  ways of reporting a error.
  Add a pointer cache to TABLE_SHARE.
2009-11-21 09:18:21 -02:00
c4d22fda0e Backport the test case for Bug#31881 "A statement is not aborted immediately if an error
inside a stored routine" from 6.0-codebase.
2009-11-21 02:06:30 +03:00
5e433c13d7 Backport the test caes for Bug#36510 from 6.0-codebase.
mysql-test/t/sp-error.test:
  Backport test of Bug#36510 (the bug itself is fixed by other
  backports, inc. SINGAL code).
2009-11-21 01:42:57 +03:00
8d33101179 Backport of:
------------------------------------------------------------
revno: 2572.23.1
committer: davi@mysql.com/endora.local
timestamp: Wed 2008-03-19 09:03:08 -0300
message:
Bug#17954 Threads_connected > Threads_created

The problem is that insert delayed threads are counted as connected
but not as created, leading to a Threads_connected value greater then
the Threads_created value.

The solution is to enforce the documented behavior that the
Threads_connected value shall be the number of currently
open connections and that Threads_created shall be the
number of threads created to handle connections.


mysql-test/r/status.result:
  Add test case result for Bug#17954
mysql-test/t/status.test:
  Add test case for Bug#17954
sql/mysqld.cc:
  Change Threads_connected to reflect the number of
  open connections. SHOW_INT type variables are not
  reset.
2009-11-20 23:30:00 +03:00
98c4476b49 Backport of:
------------------------------------------------------------
revno: 2476.1116.1
committer: davi@mysql.com/endora.local
timestamp: Fri 2007-12-14 10:10:19 -0200
message:
DROP TABLE under LOCK TABLES simultaneous to a FLUSH TABLES
WITH READ LOCK (global read lock) can lead to a deadlock.

The solution is to not wait for the global read lock if the
thread is holding any locked tables.

Related to bugs 23713 and 32395. This issues is being fixed
only on 6.0 because it depends on the fix for bug 25858 --
which was fixed only on 6.0.
2009-11-20 23:12:57 +03:00
1b34d593b5 Backport of:
------------------------------------------------------------
revno: 2476.784.3
committer: davi@moksha.local
timestamp: Tue 2007-10-02 21:27:31 -0300
message:
Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks
        
When a client (connection) holds a lock on a table and attempts to
drop (obtain a exclusive lock) on a second table that is already
held by a second client and the second client then attempts to
drop the table that is held by the first client, leads to a
circular wait deadlock. This scenario is very similar to trying to
drop (or rename) a table while holding read locks and are
correctly forbidden.
        
The solution is to allow a drop table operation to continue only
if the table being dropped is write (exclusively) locked, or if
the table is temporary, or if the client is not holding any
locks. Using this scheme prevents the creation of a circular
chain in which each client is waiting for one table that the
next client in the chain is holding.
            
This is incompatible change, as can be seen by number of tests
cases that needed to be fixed, but is consistent with respect to
behavior of the different scenarios in which the circular wait
might happen.

mysql-test/r/drop.result:
  Test case result for Bug#25858
mysql-test/r/group_by.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/insert_notembedded.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table
mysql-test/r/lock.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/lock_multi.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/myisam.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/r/view.result:
  Fix test case result wrt drop table under lock tables -- unlock tables
  before dropping table.
mysql-test/t/drop.test:
  Add test case for Bug#25858
mysql-test/t/group_by.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/insert_notembedded.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/lock_multi.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/myisam.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/query_cache_notembedded.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
mysql-test/t/view.test:
  Fix test case: unlock tables in preparation for a drop table. In some
  circumstances, dropping tables while holding locks leads to a deadlock.
sql/lock.cc:
  When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
2009-11-20 22:51:12 +03:00
39641dfd65 merge 2009-11-20 16:41:07 +01:00
34b11fb627 Merge with next-mr 2009-11-20 17:18:37 +03:00
830a772814 Enable test cases for Bug#6063 and Bug#7088. 2009-11-20 14:10:20 +01:00
3937a79886 merge of Bug#33204 (backport) 2009-11-20 13:29:43 +01:00
a21cd97c35 Bug #45261 : Crash, stored procedure + decimal
Bug #48370  Absolutely wrong calculations with GROUP BY and
  decimal fields when using IF

Added the test cases in the above two bugs for regression
testing.
Added additional tests that demonstrate a incomplete fix.
Added a new factory method for Field_new_decimal to 
create a field from an (decimal returning) Item.
In the new method made sure that all the precision and 
length variables are capped in a proper way. 
This is required because Item's can have larger precision
than the decimal fields and thus need to be capped when
creating a field based on an Item type.
Fixed the wrong typecast to Item_decimal.
2009-11-20 12:10:47 +02:00
5aeeaaf507 Manual merge of mysql-next-mr-runtime upstream. 2009-11-19 21:48:08 -02:00
405c9310cf Bug #48665: sql-bench's insert test fails due to wrong result
When merging ranges during calculation of the result of OR
to two range sets the current range may be obsoleted by the 
resulting merged range.
The first overlapping range can be obsoleted as well.

Fixed by moving the pointer to the first overlapping range to the
pointer of the resulting union range.
Added few comments at key places in key_or().
2009-11-19 18:26:19 +02:00
557afc9057 upmerge 35543,48367,48671,48806,48808 2009-11-19 10:25:57 +01:00
fc772d0d48 upmerge 35543,48367,48671,48806,48808 2009-11-19 10:24:24 +01:00
7524b96102 Postfix for Bug #47682 strange behaviour of INSERT DELAYED
Fixed a problem with the test case when executed with ps-protocol.
There the conflicing lock would be noticed during prepare, not
during execution of the insert - leading to a different (but 
equally appropriate) error message.
2009-11-18 13:49:45 +01:00
f6ec131ff9 merge 2009-11-18 11:21:26 +01:00
58f4345957 merge 2009-11-18 10:45:32 +01:00
3987c7ac4b Bug #46425 crash in Diagnostics_area::set_ok_status , empty statement,
DELETE IGNORE

The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the
diagnostics area when it happened, but the DELETE cleanup code
never checked for a non-fatal error condition, thus trying to
set diag.area to "ok".  This triggered an assert checking that
the diag.area was empty.

The fix was to test if there existed a non-fatal error condition
(thd->is_error() before ok'ing the operation.
2009-11-18 10:32:03 +01:00
41ba429286 Bug #47682 strange behaviour of INSERT DELAYED
The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
mode active. The table being inserted into had to be different from the 
table(s) locked by LOCK TABLES.

For INSERT DELAYED, the connection thread waits until the handler thread has
opened and locked its table before returning. But since the global read lock
was active, the handler thread would be unable to lock and would wait for the
global read lock to go away.

So the handler thread would be waiting for the connection thread to release
the global read lock while the connection thread was waiting for the handler
thread to lock the table. This gave a "self-deadlock" (same connection,
different threads).

The deadlock would only happen if we also had LOCK TABLES mode since the
INSERT otherwise will try to get protection against global read lock before
starting the handler thread. It will then notice that the global read lock
is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.

This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
also if we are inside LOCK TABLES mode.

Test case added to delayed.test.
2009-11-18 10:02:21 +01:00
3faaf33333 merge 2009-11-17 22:51:49 +01:00
7a6ab645ab merge 2009-11-17 22:48:28 +01:00
98fd304278 backport of bug#45904 from mysql-pe to 5.1
sql/sql_partition.cc:
  Bug#45904 Used list_of_part_fields instead of list_of_subpart_fields to discover if KEY subpartitioning => caused failure when charset=utf8 even for subpartitioning by key, would also allow for subpartitioning by hash with utf8 erroneously
2009-11-17 22:47:34 +01:00
8ff142999d Fix not_partition.test.
Patch done by Alik and received for the 5.5.0-beta build by mail.
2009-11-17 17:08:37 +01:00
e6d02a127e merge 2009-11-17 16:24:46 +01:00
8cfa50e677 Bug #48472: Loose index scan inappropriately chosen for some
WHERE conditions 
 
check_group_min_max() checks if the loose index scan 
optimization is applicable for a given WHERE condition, that is 
if the MIN/MAX attribute participates only in range predicates 
comparing the corresponding field with constants. 
 
The problem was that it considered the whole predicate suitable 
for the loose index scan optimization as soon as it encountered 
a constant as a predicate argument. This is obviously wrong for 
cases when a constant is the first argument of a predicate 
which does not satisfy the above condition. 
 
Fixed check_group_min_max() so that all arguments of the input 
predicate are considered to decide if it passes the test, even 
though a constant has already been encountered.

mysql-test/r/group_min_max.result:
  Added a test case for bug #48472.
mysql-test/t/group_min_max.test:
  Added a test case for bug #48472.
sql/opt_range.cc:
  Fixed check_group_min_max() so that all arguments of the input 
  predicate are considered to decide if it passes the test, even 
  though a constant has already been encountered.
2009-11-17 17:07:14 +03:00
bc43bff7ed Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
MySQL manual describes values of the YEAR(2) field type as follows:
values 00 - 69 mean 2000 - 2069 years and values 70 - 99 mean 1970 - 1999
years. MIN/MAX and comparison functions was comparing them as int values
thus producing wrong result.

Now the Arg_comparator class is extended with compare_year function which
performs correct comparison of the YEAR type.
The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
correctly calculate its value.
To allow Arg_comparator to use func_name() function for Item_func and Item_sum
objects the func_name declaration is moved to the Item_result_field class.
A helper function is_owner_equal_func is added to the Arg_comparator class.
It checks whether the Arg_comparator object owner is the <=> function or not.
A helper function setup is added to the Item_sum_hybrid class. It sets up
cache item and comparator.

mysql-test/r/func_group.result:
  Added a test case for the bug#43668.
mysql-test/t/func_group.test:
  Added a test case for the bug#43668.
sql/item.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Now Item_cache_int returns the type of cached item.
sql/item.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  To allow Arg_comparator to use func_name() function for Item_func and Item_sum
  objects the func_name declaration is moved to the Item_result_field class.
sql/item_cmpfunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Arg_comparator class is extended with compare_year function which
  performs correct comparison of the YEAR type.
sql/item_cmpfunc.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The year_as_datetime variable is added to the Arg_comparator class.
  It's set to TRUE when YEAR value should be converted to the
  YYYY-00-00 00:00:00 format for correct YEAR-DATETIME comparison.
sql/item_geofunc.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Item_func_spatial_rel::val_int chenged to use Arg_comparator's string
  buffers.
sql/item_subselect.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  Added an implementation of the virtual func_name function.
sql/item_sum.cc:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  A helper function setup is added to the Item_sum_hybrid class. It sets up
  cache item and comparator.
sql/item_sum.h:
  Bug#43668: Wrong comparison and MIN/MAX for YEAR(2)
  The Item_sum_hybrid class now uses Item_cache and Arg_comparator objects to
  correctly calculate its value.
  Added an implementation of the virtual func_name function.
2009-11-17 17:06:46 +03:00
5128b54c38 Post-merge fixes for backports.
mysql-test/r/sp-error.result:
  Update test case result.
mysql-test/t/dirty_close.test:
  Dirty close does not work under embedded.
mysql-test/t/sp-error.test:
  Use the specific error number so it won't catch
  other non-fatal errors.
2009-11-13 10:56:38 -02:00
63546824fc automerge 2009-11-13 13:26:16 +01:00
a120e969a8 Bug#48052: Valgrind warning - uninitialized value in
init_read_record() - (records.cc:274)
      
Item_cond::used_tables_cache was accessed in
records.cc#init_read_record() without being initialized. It had
not been initialized because it was wrongly assumed that the
Item's variables would not be accessed, and hence
quick_fix_field() was used instead of fix_fields() to save a few
CPU cycles at creation time.

The fix is to properly initilize the Item by replacing
quick_fix_field() with fix_fields().


mysql-test/r/select.result:
  Add test for BUG#48052
mysql-test/t/select.test:
  Add test for BUG#48052
sql/sql_select.cc:
  Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
2009-11-13 12:22:39 +01:00
9c23a442b2 BUG#48738: Backport patch for Bug 34582 to 5.0 codebase.
From BUG 34582 commit message:

Issuing 'FLUSH LOGS' does not close and reopen indexfile.
Instead a SEEK_SET is performed.
            
This patch makes index file to be closed and reopened whenever a
rotation happens (FLUSH LOGS is issued or binary log exceeds 
maximum configured size).
2009-11-13 10:30:56 +00:00
d8ca6b9dd9 manual merge: mysql-5.1-rep+2 (bug tree) --> mysql-5.1-rep+2 (latest)
CONFLICTS
=========

Text conflict in sql/sql_yacc.yy
1 conflicts encountered.
2009-11-13 10:17:53 +00:00
356b3df743 Bug#47627 SET @@{global.session}.local_variable in stored routine causes crash
This patch borrows ideas, text and code from Kristofer
Pettersson's patch.

An assignment of a system variable sharing the same base
name as a declared stored procedure variable in the same
context could lead to a crash.

The reason was that during the parsing of the syntactic
rule 'option_value' an uninitialized set_var object was
pushed to the parameter stack of the SET statement. The
parent rule 'option_type_value' interpreted the existence
of variables on the parameter stack as an assignment and
wrapped it in a sp_instr_set object.

As the procedure later was executed an attempt was made
to run the method 'check()' on an uninitialized member
object (NULL value) belonging to the previously created
but uninitialized object.

This patch refactors the 'internal_variable_name' rule and
copies the semantic analysis part to the depending parent
rule: 'option_value'. This makes it possible to account
for any prefixes affecting the interpretation of the
internal_variable_name.

mysql-test/r/sp.result:
  Add test case result.
mysql-test/t/sp.test:
  Add test case for bug.
sql/sql_yacc.yy:
  - Reduce churn in rule sys_option_value by moving to
    specialized functions.
  - Comment the the lookup in the rule internel_variable_name
    is a best effort operation.
  - Lookup for a system variable in the option_value if one was
    not found (the variable could have been shadowed)
2009-11-12 23:03:26 -02:00
f1abd015dc Bug #47210 first execution of "start slave until" stops too early
Until-pos guarding did not distiguish the master originated events from ones that the slave 
can introduce to the relay log e.g Rotate to the next relay log at slave restarting.
The local Rotate's coordinate are incomparable with the Until-master-pos.
That led to the unexpectable stop this bug describes.

Fixed with to avoid Until-master-pos comparison for a local slave's event.
Notice that if --replicate-same-server is true such event is treated as coming from
the master side.


mysql-test/r/rpl_until.result:
  results changed.
mysql-test/t/rpl_until.test:
  regression test for bug#47210 is added.
sql/slave.cc:
  st_relay_log_info::is_until_satisfied() is augmented with avoidance of 
  Until-master-pos comparison for a local slave's event.
  if --replicate-same-server is true such event is treated as coming from
  the master side.
sql/slave.h:
  signature of is_until_satisfied() changed to supply THD and Event to the routine.
2009-11-12 17:10:19 +02:00
552965eff9 Bug #37183 insert ignore into .. select ... hangs after
deadlock was encountered

The bug is caused by an inconsistent handling of the IGNORE
clause.  A read from a const table caused a lock timeout
(ER_LOCK_TIMEOUT) in innodb.  Since the IGNORE clause was
given, the timeout was converted into a warning instead of
an error, thus not populating the diagnostics area.  When
innodb subsequently marked the transaction for rollback,
mysql asserted since the diag.area was empty.

This patch consists of only a test case, as the bug itself
was fixed by the patch for Bug #46539
2009-11-12 12:43:33 +01:00