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
6ce3a06feb Added test case for UTF8 strings in partition constants 2009-11-02 11:03:40 +01:00
09c50b6303 auto-merge 2009-11-02 00:13:13 -08:00
d395e824ad Merge fix for BUG#43171. 2009-10-31 14:50:25 +04:00
cf8fddb910 Fixed such that we fail if using integer constants for character set fields, now need to have correct constant types 2009-10-30 21:44:41 +01:00
319e843509 Fixed so that character set constants are encoded as hex strings in frm file, but as utf8 strings in the same manner as default values in show create table and information schema tables 2009-10-30 21:08:34 +01:00
3df1ae7a1a Automerge. 2009-10-30 19:16:29 +03:00
23cbd659a0 Automerge. 2009-10-30 18:59:06 +03:00
b67cdaa351 Bug #48131: crash group by with rollup, distinct, filesort,
with temporary tables

There were two problems the test case from this bug was
triggering:

1. JOIN::rollup_init() was supposed to wrap all constant Items
into another object for queries with the WITH ROLLUP modifier
to ensure they are never considered as constants and therefore
are written into temporary tables if the optimizer chooses to
employ them for DISTINCT/GROUP BY handling.

However, JOIN::rollup_init() was called before
make_join_statistics(), so Items corresponding to fields in
const tables could not be handled as intended, which was
causing all kinds of problems later in the query execution. In
particular, create_tmp_table() assumed all constant items
except "hidden" ones to be removed earlier by remove_const()
which led to improperly initialized Field objects for the
temporary table being created. This is what was causing crashes
and valgrind errors in storage engines.

2. Even when the above problem had been fixed, the query from
the test case produced incorrect results due to some
DISTINCT/GROUP BY optimizations being performed by the
optimizer that are inapplicable in the WITH ROLLUP case.

Fixed by disabling inapplicable DISTINCT/GROUP BY optimizations
when the WITH ROLLUP modifier is present, and splitting the
const-wrapping part of JOIN::rollup_init() into a separate
method which is now invoked after make_join_statistics() when
the const tables are already known.

mysql-test/r/olap.result:
  Added a test case for bug #48131.
mysql-test/t/olap.test:
  Added a test case for bug #48131.
sql/sql_select.cc:
  1. Disabled inapplicable DISTINCT/GROUP BY optimizations when
  the WITH ROLLUP modifier is present.
  2. Split the const-wrapping part of JOIN::rollup_init() into a
  separate method.
sql/sql_select.h:
  Added rollup_process_const_fields() declaration.
2009-10-30 18:54:53 +03:00
5bba20bb6a merge 2009-10-30 16:13:13 +02:00
9d96cd6dcb Bug #48291 : crash with row() operator,select into @var, and
subquery returning multiple rows

Error handling was missing when handling subqueires in WHERE 
and when assigning a SELECT result to a @variable.
This caused crash(es). 

Fixed by adding error handling code to both the WHERE 
condition evaluation and to assignment to an @variable.
2009-10-30 15:15:43 +02:00
1e7fb59272 merge 2009-10-30 11:56:32 +02:00
851e250953 Bug #48293: crash with procedure analyse, view with > 10 columns,
having clause...

The fix for bug 46184 was not very complete. It was not covering
views using temporary tables and multiple tables in a FROM clause.
Fixed by reverting the fix for 46184 and making a more general
check that is checking at the right execution stage and for all
of the non-supported cases.
Now PROCEDURE ANALYZE on non-top level SELECT is also forbidden.
Updated the analyse.test and subselect.test accordingly.
2009-10-30 11:40:44 +02:00
bba3b76cdb merge 2009-10-30 10:03:18 +02:00
be04d1a479 Bug#48319: Server crashes on "GRANT/REVOKE ... TO CURRENT_USER"
CURRENT_USER() in GRANT ... TO CURRENT_USER() only gave us a definer,
not a full user (i.e., password-element was not initiliazed). Hence
dereferencing the password led to a crash.

Properly initializes definers now, just so there are no misunderstandings.
Also does some magic so IDENTIFIED BY ... works with CURRENT_USER().

mysql-test/r/grant2.result:
  Show GRANT ... TO CURRENT_USER() no longer crashes.
  Show it to work with IDENTIFIED BY to boot.
mysql-test/t/grant2.test:
  Show GRANT ... TO CURRENT_USER() no longer crashes.
  Show it to work with IDENTIFIED BY to boot.
sql/sql_acl.cc:
  Make IDENTIFIED BY ... work with CURRENT_USER()
sql/sql_parse.cc:
  Zero password-part of definer just in case somebody mistakes this for
  a complete LEX_USER!
2009-10-29 22:06:10 -07:00
eaad6119da Bug#48295: explain extended crash with subquery and ONLY_FULL_GROUP_BY sql_mode
If an outer query is broken, a subquery might not even get set up.
EXPLAIN EXTENDED did not expect this and merrily tried to de-ref all
of the half-setup info.

We now catch this case and print as much as we have, as it doesn't cost us
anything (doesn't make regular execution slower).

mysql-test/r/explain.result:
  Show that EXPLAIN EXTENDED with subquery and illegal out query doesn't crash.
  Show also that SHOW WARNINGS will render an additional Note in the hope of
  being, well, helpful.
mysql-test/t/explain.test:
  If we have only half a query for EXPLAIN EXTENDED to print (i.e.,
  incomplete subquery info as outer query is illegal), we should
  provide the user with as much info as we easily can if they ask
  for it. What we should not do is crash when they come asking for
  help, that violates etiquette in some countries.
sql/item_subselect.cc:
  If the sub-query's actually set up, print it. Otherwise, elide.
2009-10-29 16:01:54 -07:00
caa4fffa00 Changed COLUMN_LIST to COLUMNS after arch review 2009-10-29 18:04:23 +01:00
63e732fe61 Bug#33637 SHOW PROCEDURE CODE/SHOW FUNCTION CODE sp_name gives a syntax error.
Backport for 5.5

In non debug builds, the statements:
- SHOW PROCEDURE CODE
- SHOW FUNCTION CODE
used to fail with a "syntax error", which is misleading.

These statements have been changed to return the following error for non
debug builds:
ERROR HY000: The 'SHOW PROCEDURE|FUNCTION CODE' feature is disabled; you
need MySQL built with '--with-debug' to have it working

For debug builds (./configure --with-debug), nothing is changed.
2009-10-29 10:51:04 -06:00
ac37324843 Bug #42116 : Mysql crash on specific query
Queries with nested outer joins may lead to crashes or 
bad results because an internal data structure is not handled
correctly.
The optimizer uses bitmaps of nested JOINs to determine
if certain table can be placed at a certain place in the
JOIN order.
It does maintain a bitmap describing in which JOINs 
last placed table is nested.
When it puts a table it makes sure the bit of every JOIN that
contains the table in question is set (because JOINs can be nested).
It does that by recursively setting the bit for the next enclosing
JOIN when this is the first table in the JOIN and recursively 
resetting the bit if it's the last table in the JOIN.
When it removes a table from the join order it should do the
opposite : recursively unset the bit if it's the only remaining 
table in this join and and recursively set the bit if it's removing
the last table of a JOIN.
There was an error in how the bits was set for the upper levels :
when removing a table it was setting the bit for all the enclosing 
nested JOINs even if there were more tables left in the current JOIN
(which practically means that the upper nested JOINs were not affected).
Fixed by stopping the recursion at the relevant level.

mysql-test/r/join.result:
  Bug #42116: test case
mysql-test/t/join.test:
  Bug #42116: test case
sql/sql_select.cc:
  Bug #41116: don't go up and set the bits if more tables in
  at the current JOIN level
2009-10-29 17:24:29 +02:00
f236f9a9dc Automerge from mysql-next-mr. 2009-10-29 18:03:30 +03:00
ddcdacb297 Bug#38551 query cache can still consume [very little] cpu time even when it is off.
When the query cache is disabled, the server shouldn't attempt to take the 
query cache mutex.
                             
By using the command line option --query_cache_type=0, the user can disable
   
(backport from mysql-pe)


mysql-test/t/query_cache_disabled-master.opt:
  * added test case for bug38551
mysql-test/t/query_cache_disabled.test:
  * added test case for bug38551
sql/set_var.cc:
  * Added before-trigger to verify that query_cache_type wasn't turned off or on during
  runtime.
sql/set_var.h:
  * Changed order on how the enumeration is processed. By first projecting the
  character representation of the variable to a temporary integer we can have
  one function instead of two to check if the value is valid.
sql/share/errmsg-utf8.txt:
  * Added error message for query cache disabled state
sql/sql_cache.cc:
  * If the query cache is disabled at start up, shorten the execution path and avoid
  grabbing the query cache mutex each time the invalidate interface methods are called.
sql/sql_cache.h:
  * Added new methods to set the query cache into a disabled state.
2009-10-29 12:19:36 +01:00
18f63cbcb9 A postfix for Bug#46633 Obsolete Serbian locale name
Re-Allowing sr_YU with a "deprecated" warning.
2009-10-29 15:10:36 +04:00
eff49de23e mysql_upgrade test fixed
per-file comments:
  mysql-test/r/mysql_upgrade.result
     result updated
  mysql-test/t/mysql_upgrade.test
     --skip-verbose option added to the call
2009-10-29 10:03:16 +04:00
470a44c70d Fixed code review change to ensure that VALUES constants are of the same result type as the field they are constants for 2009-10-28 19:20:32 +01:00
072c13d939 Merged WL#3352 into mysql-next-mr 2009-10-28 18:22:36 +01:00
17ed708975 BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null()
XA START may cause assertion failure/server crash when it is called
after unilateral roll back issued by the Resource Manager (both
in regular transaction and after XA transaction).

The problem was that rm_error variable wasn't set/reset properly.

mysql-test/r/xa.result:
  A test case for BUG#43171.
mysql-test/t/xa.test:
  A test case for BUG#43171.
sql/handler.cc:
  Setting rm_error when we're out of XA transaction has no
  special meaning. But it blocks reset of thd->transaction.xid
  structure later.
sql/sql_parse.cc:
  Reset rm_error before we enter ha_rollback(), so
  thd->transaction.xid strucure is reinitialized.
2009-10-28 19:39:08 +04:00
f130de4fb8 A patch and a test case for
Bug#46539 Various crashes on INSERT IGNORE SELECT + SELECT FOR UPDATE.

If a transaction was rolled back inside InnoDB due to a deadlock
or lock wait timeout, and the statement had IGNORE clause,
the server could crash at the end of the statement or on shutdown.

This was caused by the error handling infrastructure's attempt to 
ignore a non-ignorable error.

When a transaction rollback request is raised, switch off 
current_select->no_error flag, so that the following error
won't be ignored.

Instead, we could add !thd->is_fatal_sub_stmt_error to
my_message_sql(), but since in write_record() we switch
off no_error, the same approach is used in 
thd_mark_transaction_to_rollback().

@todo: call thd_mark_transaction_to_rollback() from 
handler::print_error(), then we can easily make sure
that the error reported by print_error is not ignored.

mysql-test/r/innodb_lock_wait_timeout_1.result:
  Update results (Bug#46539).
mysql-test/t/innodb_lock_wait_timeout_1.test:
  Add a test case for Bug#46539
sql/sql_class.cc:
  When a transaction rollback request is raised, switch of 
  current_select->no_error flag, so that the following error
  won't be ignored.
2009-10-28 17:49:56 +03:00
36299d59ef WL#4991 mysql_upgrade --fix-privilege-tables
(backport)
   mysql_upgrade script accepts --upgrade-system-tables option,
   fixing only system tables in this case.

per-file comments:
  client/mysql_upgrade.c
WL#4991 mysql_upgrade --fix-privilege-tables
    --upgrade-system-tables option added.
   if it is set, the tool won't look for the mysqlcheck then
   run_mysqlcheck_fixnames() and run_mysqlcheck_upgrade won't be called.
  mysql-test/r/mysql_upgrade.result
WL#4991 mysql_upgrade --fix-privilege-tables
    test result added
  mysql-test/t/mysql_upgrade.test
WL#4991 mysql_upgrade --fix-privilege-tables
    test case added
2009-10-28 14:02:00 +04:00
22fe8e10e2 Merge from mysql-next-mr. 2009-10-28 10:55:44 +03:00
55b8f07a99 Automerge from mysql-next-mr. 2009-10-28 10:48:53 +03:00
10fed1aca0 BUG#48165, needed to introduce length restrictions on partitioning fields to ensure that no stack overruns occur 2009-10-28 01:11:17 +01:00
cc43a2089c Fixed sql_mode issue in BUG#48164, will ignore sql_mode when generating constants, also warnings will not be tolerated 2009-10-28 00:06:11 +01:00
a5b5db32b4 Merge 5.1-bugteam -> 5.1-bugteam-local. 2009-10-27 18:30:02 +04:00
578007404d A follow-up to fix for
BUG#47073 - valgrind errs, corruption,failed repair of partition,
            low myisam_sort_buffer_size

Fixed race conditions discovered with the provided test case and
stabilized test case.

include/myisam.h:
  Serialize submission of messages from multi-threaded REPAIR.
mysql-test/r/myisam.result:
  REPAIR output highly depend on threads activity. Disabled
  result log to make test case deterministic.
mysql-test/t/myisam.test:
  REPAIR output highly depend on threads activity. Disabled
  result log to make test case deterministic.
storage/myisam/ha_myisam.cc:
  Serialize submission of messages from multi-threaded REPAIR.
storage/myisam/mi_check.c:
  Serialize submission of messages from multi-threaded REPAIR.
storage/myisam/sort.c:
  Only master thread is allowed to detach write cache from
  the share.
2009-10-27 18:27:27 +04:00
313c5a01ee Bug #47930: MATCH IN BOOLEAN MODE returns too many results
inside subquery

Re-setting a fulltext index was a no-operation if not all
the matches of a search were consumed by reading them.
This was preventing a joined table using a fulltext index
in a subquery that requires only 1 row of output (e.g. EXISTS) 
from working correctly because the second execution of the 
sub-query has the fulltext index cursor in a wrong state and
was not finding results.
Fixed by making the re-init code _ftb_init_index_search() 
to re-set open cursors in addition to depleted ones.
2009-10-27 14:43:12 +02:00
bbbad7fee5 merge 2009-11-10 12:59:02 +02:00
0daad80228 merge 2009-11-10 10:58:43 +02:00
3823ac329e automerge 2009-10-27 15:04:59 +04:00
f554a3c094 5.0-bugteam->5.1-bugteam merge 2009-10-27 14:09:36 +04:00
47c9089ef5 Automerge from mysql-next-mr. 2009-10-27 12:59:09 +03:00
cd6e159890 Automerge from mysql-next-mr. 2009-10-27 12:57:44 +03:00
6ceaf234bb auto-merge 2009-10-27 02:53:16 -07:00
1e5804f2c5 Fixed lock_sync.test failure in mysql-next-mr tree in embedded mode.
Disabled execution of this test for embedded server until fix for
bug 41971 'Thread state on embedded server is always "Writing to net"'
is back-ported to this tree.
2009-10-27 12:43:40 +03:00
a4068d17fd Test postfix for Bug#43138 (DROP DATABASE failure does not
clean up message list).
2009-10-27 11:54:27 +03:00
f0a7ff8419 Bug#41049 does syntax "grant" case insensitive?
Problem 1:
column_priv_hash uses utf8_general_ci collation
for the key comparison. The key consists of user name,
db name and table name. Thus user with privileges on table t1
is able to perform the same operation on T1
(the similar situation with user name & db name, see acl_cache).
So collation which is used for column_priv_hash and acl_cache
should be case sensitive.
The fix:
replace system_charset_info with my_charset_utf8_bin for
column_priv_hash and acl_cache
Problem 2:
The same situation with proc_priv_hash, func_priv_hash,
the only difference is that Routine name is case insensitive.
So the fix is to use my_charset_utf8_bin for
proc_priv_hash & func_priv_hash and convert routine name into lower
case before writing the element into the hash and
before looking up the key.
Additional fix: mysql.procs_priv Routine_name field collation
is changed to utf8_general_ci.
It's necessary for REVOKE command
(to find a field by routine hash element values).
Note: 
It's safe for lower-case-table-names mode too because
db name & table name are converted into lower case
(see GRANT_NAME::GRANT_NAME).


mysql-test/include/have_case_insensitive_fs.inc:
  test case
mysql-test/r/case_insensitive_fs.require:
  test case
mysql-test/r/grant_lowercase_fs.result:
  test result
mysql-test/r/lowercase_fs_off.result:
  test result
mysql-test/r/ps_grant.result:
  test result
mysql-test/r/system_mysql_db.result:
  changed Routine_name field collation to case insensitive
mysql-test/t/grant_lowercase_fs.test:
  test case
mysql-test/t/lowercase_fs_off.test:
  test case
scripts/mysql_system_tables.sql:
  changed Routine_name field collation to case insensitive
scripts/mysql_system_tables_fix.sql:
  changed Routine_name field collation to case insensitive
sql/sql_acl.cc:
  Problem 1:
  column_priv_hash uses utf8_general_ci collation
  for the key comparison. The key consists of user name,
  db name and table name. Thus user with privileges on table t1
  is able to perform the same operation on T1
  (the similar situation with user name & db name, see acl_cache).
  So collation which is used for column_priv_hash and acl_cache
  should be case sensitive.
  The fix:
  replace system_charset_info with my_charset_utf8_bin for
  column_priv_hash and acl_cache
  Problem 2:
  The same situation with proc_priv_hash, func_priv_hash,
  the only difference is that Routine name is case insensitive.
  So the fix is to use my_charset_utf8_bin for
  proc_priv_hash & func_priv_hash and convert routine name into lower
  case before writing the element into the hash and
  before looking up the key.
  Additional fix: mysql.procs_priv Routine_name field collation
  is changed to utf8_general_ci.
  It's necessary for REVOKE command
  (to find a field by routine hash element values).
  Note: 
  It's safe for lower-case-table-names mode too because
  db name & table name are converted into lower case
  (see GRANT_NAME::GRANT_NAME).
2009-10-27 12:09:19 +04:00
381ad2ec6a A postfix for WL#1349
Fixing locale name: en_US.UTF-8 -> en_US.utf8
2009-10-27 08:38:32 +04:00
86c23fa708 Fix for bug #45143 "All connections hang on concurrent ALTER TABLE".
Concurrent execution of statements which require non-table-level
write locks on several instances of the same table (such as
SELECT ... FOR UPDATE which uses same InnoDB table twice or a DML
statement which invokes trigger which tries to update same InnoDB
table directly and through stored function) and statements which
required table-level locks on this table (e.g. LOCK TABLE ... WRITE,
ALTER TABLE, ...) might have resulted in a deadlock.

The problem occured when a thread tried to acquire write lock
(TL_WRITE_ALLOW_WRITE) on the table but had to wait since there was
a pending write lock (TL_WRITE, TL_WRITE_ALLOW_READ) on this table
and we failed to detect that this thread already had another instance
of write lock on it (so in fact we were trying to acquire recursive
lock) because there was also another thread holding write lock on the
table (also TL_WRITE_ALLOW_WRITE). When the latter thread released
its lock neither the first thread nor the thread trying to acquire
TL_WRITE/TL_WRITE_ALLOW_READ were woken up (as table was still write
locked by the first thread) so we ended up with a deadlock.

This patch solves this problem by ensuring that thread which
already has write lock on the table won't wait when it tries
to acquire second write lock on the same table.

mysql-test/r/lock_sync.result:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysql-test/t/lock_sync.test:
  Added test case for bug #45143 "All connections hang on concurrent
  ALTER TABLE".
mysys/thr_lock.c:
  Ensured that thread can acquire write lock on the table without
  waiting if it already has write lock on it even if there are other
  threads holding write locks on this table (this is normal situation
  for, e.g., TL_WRITE_ALLOW_WRITE type of lock).
  
  Adjusted comments to better explain why it is OK to do so and added
  asserts to prevent introduction of scenarios in which this can cause
  problems.
2009-10-26 22:38:03 +03:00
4723ae6d0c A postfix for WL#1349: Fixing test failire problems on HP-UX 2009-10-26 16:29:41 +04:00
9a5a77eb68 automerge 2009-10-24 09:57:31 +03:00
1339fb17fe Auto-merge. 2009-10-23 23:37:57 +05:00
c2d3d6bbef automerge 2009-10-23 16:35:06 +02:00