3544 Commits

Author SHA1 Message Date
Sergei Golubchik
474fe6d9d9 fixes for test failures
and small collateral changes

mysql-test/lib/My/Test.pm:
  somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
  this differs, because we don't rewrite general log queries, and multi-statement
  packets are logged as a one entry. this result file is identical to what mysql-5.6.5
  produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
  MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
  MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
  this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
  do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
  will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
  will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
Michael Widenius
620d14f8c3 Automatic merge 2012-09-22 17:11:40 +03:00
Michael Widenius
3e83c4e8f9 Automatic merge 2012-09-22 15:30:24 +03:00
Michael Widenius
32e4c7e138 Added THD::utime_after_query to avoid calling current_utime() twice for every end-of-query
Increment long_query_count also if thd->variables.log_slow_rate_limit is used
Added new state "Writing to binlog"


sql/sql_class.h:
  Added THD::utime_after_query to avoid calling current_utime() twice for every end-of-query
sql/sql_parse.cc:
  Increment long_query_count also if thd->variables.log_slow_rate_limit is used
  Removed extra calls to thd_proc_info(thd, "logging slow query") and thd->current_utime();
sql/sql_table.cc:
  Added new state "Writing to binlog"
2012-09-13 21:11:47 +03:00
unknown
288eeb3a31 MDEV-232: Remove one fsync() from commit phase.
Introduce a new storage engine API method commit_checkpoint_request().
This is used to replace the fsync() at the end of every storage engine
commit with a single fsync() when a binlog is rotated.

Binlog rotation is now done during group commit instead of being
delayed until unlog(), removing some server stall and avoiding an
expensive lock/unlock of LOCK_log inside unlog().
2012-09-13 14:31:29 +02:00
Michael Widenius
3a793b9d4d Added new status variables:
feature_dynamic_columns,feature_fulltext,feature_gis,feature_locale,feature_subquery,feature_timezone,feature_trigger,feature_xml
Opened_views, Executed_triggers, Executed_events
Added new process status 'updating status' as part of 'freeing items'

mysql-test/r/features.result:
  Test of feature_xxx status variables
mysql-test/r/mysqld--help.result:
  Removed duplicated 'language' variable.
mysql-test/r/view.result:
  Test of opened_views
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
  Write more information on failure
mysql-test/t/features.test:
  Test of feature_xxx status variables
mysql-test/t/view.test:
  Test of opened_views
sql/event_scheduler.cc:
  Increment executed_events status variable
sql/field.cc:
  Increment status variable
sql/item_func.cc:
  Increment status variable
sql/item_strfunc.cc:
  Increment status variable
sql/item_subselect.cc:
  Increment status variable
sql/item_xmlfunc.cc:
  Increment status variable
sql/mysqld.cc:
  Add new status variables to 'show status'
sql/mysqld.h:
  Added executed_events
sql/sql_base.cc:
  Increment status variable
sql/sql_class.h:
  Add new status variables
sql/sql_parse.cc:
  Added new process status 'updating status' as part of 'freeing items'
sql/sql_trigger.cc:
  Increment status variable
sql/sys_vars.cc:
  Increment status variable
sql/tztime.cc:
  Increment status variable
2012-09-09 01:22:06 +03:00
Michael Widenius
5139238685 Switch automaticly to statement based replication for statements that can't generate row based events. This is needed to avoid getting
updates to system, statistics and admin tables logged to binary log.
- Removed special code used to temporarily change to statement based replication.
- Changed to a faster and smaller interface for temporarily switching to statement based replication.

sql/event_db_repository.cc:
  Change to new interface to not use row based replication for system table changes.
sql/events.cc:
  Change to new interface to not use row based replication for system table changes.
sql/sp.cc:
  Removed temporarily switching to statement based replication (this is now done automaticly in mysql_execute_command())
sql/sql_acl.cc:
  Change to new interface to not use row based replication for system table changes.
  Removed temporarily switching to statement based replication (this is now done automaticly in mysql_execute_command())
sql/sql_class.h:
  Added new interface for temporarily switching to statement based replication.
sql/sql_parse.cc:
  Mark commands that needs original replication mode with CF_FORCE_ORIGINAL_BINLOG_FORMAT.
  Switch automaticly to statement based replication for statements that can't generate row based events (and can't change replication mode)
sql/sql_udf.cc:
  Removed temporarily switching to statement based replication (this is now done automaticly in mysql_execute_command())
2012-09-04 19:26:30 +03:00
Igor Babaev
98f239a849 Merge 5.5->5.5-mwl248. 2012-08-29 18:50:38 -07:00
Michael Widenius
653492fb23 More DBUG_ENTER, to make it easier to find out where free_root(thd->mem_root) is called 2012-08-22 18:03:31 +03:00
Sergei Golubchik
f72a765997 5.2 merge.
two tests still fail:
  main.innodb_icp and main.range_vs_index_merge_innodb
  call records_in_range() with both range ends being open
  (which triggers an assert)
2012-08-22 16:45:25 +02:00
Sergei Golubchik
1fd8150a5b 5.1 merge
increase xtradb verson from 13.0 to 13.01
2012-08-22 16:13:54 +02:00
Sergei Golubchik
cefc30b166 merge with MySQL 5.1.65 2012-08-22 11:40:39 +02:00
Igor Babaev
822e5da0d0 Merge 5.5->5.5-mwl248 2012-08-14 12:42:14 -07:00
Michael Widenius
60589aeee0 Next part of merge. See TODO for details 2012-08-14 17:23:34 +03:00
Sergey Petrunya
4d8be2d4f6 MWL#182: Explain running statements: merge with 5.5-main 2012-08-12 15:07:53 +04:00
Michael Widenius
b39e6e3d09 Added support of thd->tx_read_only
Moved timestamp handling from all handler::write() methods in the storage engines to handler::ha_write

sql/handler.cc:
  Added PSI_CALL's
2012-08-07 07:25:15 +03:00
Michael Widenius
1d0f70c2f8 Temporary commit of merge of MariaDB 10.0-base and MySQL 5.6 2012-08-01 17:27:34 +03:00
Sergei Golubchik
42ea25d4c5 MDEV-375 Server crashes in THD::print_aborted_warning with log_warnings > 3
Don't use ER(xxx) in THD::close_connection(), when current_thd is already reset to NULL.
Prefer ER_THD() or ER_DEFAULT() instead.
2012-07-31 18:32:46 +02:00
Sergey Petrunya
2b0f6ece7b Merge 5.5-main -> 5.5-show-explain 2012-07-25 20:53:49 +04:00
Sergey Petrunya
2368f8895d MWL#182: Explain running statements
- Address feedback from the second code review.
2012-07-17 21:52:08 +04:00
Sergey Petrunya
f913ba7a60 MWL#182: Explain running statements: address review feedback
- Make THD::check_killed() an inline function which makes calls to non-inline 
  functions only whern there are APC requests to be served.
2012-07-11 13:39:56 +04:00
Sergey Petrunya
725d76e1e8 MWL#182: Explain running statements: address review feedback
- switch SHOW EXPLAIN to using an INFORMATION_SCHEMA table.
2012-07-10 21:23:00 +04:00
Sergey Petrunya
b9093d370b MWL#182: Explain running statements: address review feedback
- Fix the year in Monty Program Ab copyrights in the new files.
- Fix permissions handling so that SHOW EXPLAIN's handling is the 
  same as SHOW PROCESSLIST's.
2012-06-29 22:17:16 +04:00
Sergey Petrunya
c62c0c5516 MWL#182: Explain running statements: address review feedback
- Add Monty Program Ab copyright in new files
- Change Apc_target::make_apc_call() to accept a C++-style
  functor (instead of C-style function + parameter)
2012-06-28 13:58:37 +04:00
Igor Babaev
4a6a08309c Merge 5.5 -> 5.5-mwl248. 2012-06-26 11:37:48 -07:00
Kent Boortz
5f86ecbf36 Solve a linkage problem with "libmysqld" on several Solaris platforms:
a multiple definition of 'THD::clear_error()' in (at least)
libmysqld.a(lib_sql.o) and libmysqld.a(libfederated_a-ha_federated.o).

Patch provided by Ramil Kalimullin.
2012-06-26 16:30:15 +02:00
Kent Boortz
3de8d224cf Solve a linkage problem with "libmysqld" on several Solaris platforms:
a multiple definition of 'THD::clear_error()' in (at least)
libmysqld.a(lib_sql.o) and libmysqld.a(libfederated_a-ha_federated.o).

Patch provided by Ramil Kalimullin.
2012-06-26 16:30:15 +02:00
Sergey Petrunya
8c762965d3 Merge 5.3 -> 5.5 2012-06-20 15:01:28 +04:00
Sergey Petrunya
6eb2ce5863 SHOW EXPLAIN: better comments 2012-06-19 18:10:32 +04:00
unknown
0b93b444b6 Merged the fix for bug lp:944706, mdev-193 2012-06-19 15:06:45 +03:00
Sergey Petrunya
90fbd8b22b Merge 5.2->5.3 2012-06-18 22:38:11 +04:00
Sergey Petrunya
fb33db5608 MWL#182: Explain running statements
- Merge with current 5.5-main
2012-06-15 00:50:17 +04:00
Sergei Golubchik
0522307ed1 mysql-5.5 merge 2012-06-14 20:05:31 +02:00
Sergey Petrunya
5eecea8caf MDEV-324: SHOW EXPLAIN: Plan produced by SHOW EXPLAIN for a query with TEMPTABLE view loses 'DERIVED' line
- Make SHOW EXPLAIN code take into account that st_select_lex object without joins can be
  a full-featured SELECTs which were already executed and cleaned up.
2012-06-07 19:55:22 +04:00
unknown
c2677de7ac Merge the fix for lp:944706, mdev-193 2012-06-06 22:26:40 +03:00
Igor Babaev
f549f495f7 Removed the server option --stat-tables.
Renamed the system variable optimizer_use_stat_tables to use_stat_tables.
This variable now has only 3 possible values:
'never', 'complementary', 'preferably'.
If the server has been launched with
--use-stat-tables='complementary'|'preferably'
then the statictics tables can be employed by the optimizer and by the
ANALYZE command.
2012-06-02 17:19:01 -07:00
Igor Babaev
27ab01243c Merge 2012-06-01 13:42:39 -07:00
Praveenkumar Hulakund
b2c3acc987 Bug#14003080:65104: MAX_USER_CONNECTIONS WITH PROCESSLIST EMPTY
Analysis:
-------------
If server is started with limit of MAX_CONNECTIONS and 
MAX_USER_CONNECTIONS then only MAX_USER_CONNECTIONS of any particular
users can be connected to server and total MAX_CONNECTIONS of client can
be connected to server.

Server maintains a counter for total CONNECTIONS and total CONNECTIONS 
from particular user.

Here, MAX_CONNECTIONS of connections are created to server. Out of this
MAX_CONNECTIONS, connections from particular user (say USER1) are
also created. The connections from USER1 is lesser than 
MAX_USER_CONNECTIONS. After that there was one more connection request from
USER1. Since USER1 can still create connections as he havent reached
MAX_USER_CONNECTIONS, server increments counter of CONNECTIONS per user.
As server already has MAX_CONNECTIONS of connections, next check to total
CONNECTION count fails. In this case control is returned WITHOUT 
decrementing the CONNECTIONS per user. So the counter per user CONNECTIONS goes
on incrementing for each attempt until current connections are closed. 
And because of this counter per CONNECTIONS reached MAX_USER_CONNECTIONS. 
So, next connections form USER1 user always returns with MAX_USER_CONNECTION 
limit error, even when total connection to sever are less than MAX_CONNECTIONS.

Fix:
-------------
This issue is occurred because of not handling counters properly in the
server. Changed the code to handle per user connection counters properly.
2012-05-28 11:14:43 +05:30
Praveenkumar Hulakund
ca9a3a8915 Bug#14003080:65104: MAX_USER_CONNECTIONS WITH PROCESSLIST EMPTY
Analysis:
-------------
If server is started with limit of MAX_CONNECTIONS and 
MAX_USER_CONNECTIONS then only MAX_USER_CONNECTIONS of any particular
users can be connected to server and total MAX_CONNECTIONS of client can
be connected to server.

Server maintains a counter for total CONNECTIONS and total CONNECTIONS 
from particular user.

Here, MAX_CONNECTIONS of connections are created to server. Out of this
MAX_CONNECTIONS, connections from particular user (say USER1) are
also created. The connections from USER1 is lesser than 
MAX_USER_CONNECTIONS. After that there was one more connection request from
USER1. Since USER1 can still create connections as he havent reached
MAX_USER_CONNECTIONS, server increments counter of CONNECTIONS per user.
As server already has MAX_CONNECTIONS of connections, next check to total
CONNECTION count fails. In this case control is returned WITHOUT 
decrementing the CONNECTIONS per user. So the counter per user CONNECTIONS goes
on incrementing for each attempt until current connections are closed. 
And because of this counter per CONNECTIONS reached MAX_USER_CONNECTIONS. 
So, next connections form USER1 user always returns with MAX_USER_CONNECTION 
limit error, even when total connection to sever are less than MAX_CONNECTIONS.

Fix:
-------------
This issue is occurred because of not handling counters properly in the
server. Changed the code to handle per user connection counters properly.
2012-05-28 11:14:43 +05:30
unknown
d56f5dae1e Fix bug lp:1001506
This is a backport of the (unchaged) fix for MySQL bug #11764372, 57197.

Analysis:

When the outer query finishes its main execution and computes GROUP BY,
it needs to construct a new temporary table (and a corresponding JOIN) to
execute the last DISTINCT operation. At this point JOIN::exec calls
JOIN::join_free, which calls JOIN::cleanup -> TMP_TABLE_PARAM::cleanup
for both the outer and the inner JOINs. The call to the inner
TMP_TABLE_PARAM::cleanup sets copy_field = NULL, but not copy_field_end.

The final execution phase that computes the DISTINCT invokes:
evaluate_join_record -> end_write -> copy_funcs
The last function copies the results of all functions into the temp table.
copy_funcs walks over all functions in join->tmp_table_param.items_to_copy.
In this case items_to_copy contains both assignments to user variables.
The process of copying user variables invokes Item_func_set_user_var::check
which in turn re-evaluates the arguments of the user variable assignment.
This in turn triggers re-evaluation of the subquery, and ultimately
copy_field.

However, the previous call to TMP_TABLE_PARAM::cleanup for the subquery
already set copy_field to NULL but not its copy_field_end. This results
in a null pointer access, and a crash.

Fix:
Set copy_field_end and save_copy_field_end to null when deleting
copy fields in TMP_TABLE_PARAM::cleanup().
2012-05-23 18:18:08 +03:00
Gopal Shankar
21faded51e Bug#12636001 : deadlock from thd_security_context
PROBLEM:
Threads end-up in deadlock due to locks acquired as described
below,

con1: Run Query on a table. 
  It is important that this SELECT must back-off while
  trying to open the t1 and enter into wait_for_condition().
  The SELECT then is blocked trying to lock mysys_var->mutex
  which is held by con3. The very significant fact here is
  that mysys_var->current_mutex will still point to LOCK_open,
  even if LOCK_open is no longer held by con1 at this point.

con2: Try dropping table used in con1 or query some table.
  It will hold LOCK_open and be blocked trying to lock
  kernel_mutex held by con4.

con3: Try killing the query run by con1.
  It will hold THD::LOCK_thd_data belonging to con1 while
  trying to lock mysys_var->current_mutex belonging to con1.
  But current_mutex will point to LOCK_open which is held
  by con2.

con4: Get innodb engine status
  It will hold kernel_mutex, trying to lock THD::LOCK_thd_data
  belonging to con1 which is held by con3.

So while technically only con2, con3 and con4 participate in the
deadlock, con1's mysys_var->current_mutex pointing to LOCK_open
is a vital component of the deadlock.

CYCLE = (THD::LOCK_thd_data -> LOCK_open ->
         kernel_mutex -> THD::LOCK_thd_data)

FIX:
LOCK_thd_data has responsibility of protecting,
1) thd->query, thd->query_length
2) VIO
3) thd->mysys_var (used by KILL statement and shutdown)
4) THD during thread delete.

Among above responsibilities, 1), 2)and (3,4) seems to be three
independent group of responsibility. If there is different LOCK
owning responsibility of (3,4), the above mentioned deadlock cycle
can be avoid. This fix introduces LOCK_thd_kill to handle
responsibility (3,4), which eliminates the deadlock issue.

Note: The problem is not found in 5.5. Introduction MDL subsystem 
caused metadata locking responsibility to be moved from TDC/TC to
MDL subsystem. Due to this, responsibility of LOCK_open is reduced. 
As the use of LOCK_open is removed in open_table() and 
mysql_rm_table() the above mentioned CYCLE does not form.
Revision ID for changes,
open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz
mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw
2012-05-17 18:07:59 +05:30
Gopal Shankar
047fea0682 Bug#12636001 : deadlock from thd_security_context
PROBLEM:
Threads end-up in deadlock due to locks acquired as described
below,

con1: Run Query on a table. 
  It is important that this SELECT must back-off while
  trying to open the t1 and enter into wait_for_condition().
  The SELECT then is blocked trying to lock mysys_var->mutex
  which is held by con3. The very significant fact here is
  that mysys_var->current_mutex will still point to LOCK_open,
  even if LOCK_open is no longer held by con1 at this point.

con2: Try dropping table used in con1 or query some table.
  It will hold LOCK_open and be blocked trying to lock
  kernel_mutex held by con4.

con3: Try killing the query run by con1.
  It will hold THD::LOCK_thd_data belonging to con1 while
  trying to lock mysys_var->current_mutex belonging to con1.
  But current_mutex will point to LOCK_open which is held
  by con2.

con4: Get innodb engine status
  It will hold kernel_mutex, trying to lock THD::LOCK_thd_data
  belonging to con1 which is held by con3.

So while technically only con2, con3 and con4 participate in the
deadlock, con1's mysys_var->current_mutex pointing to LOCK_open
is a vital component of the deadlock.

CYCLE = (THD::LOCK_thd_data -> LOCK_open ->
         kernel_mutex -> THD::LOCK_thd_data)

FIX:
LOCK_thd_data has responsibility of protecting,
1) thd->query, thd->query_length
2) VIO
3) thd->mysys_var (used by KILL statement and shutdown)
4) THD during thread delete.

Among above responsibilities, 1), 2)and (3,4) seems to be three
independent group of responsibility. If there is different LOCK
owning responsibility of (3,4), the above mentioned deadlock cycle
can be avoid. This fix introduces LOCK_thd_kill to handle
responsibility (3,4), which eliminates the deadlock issue.

Note: The problem is not found in 5.5. Introduction MDL subsystem 
caused metadata locking responsibility to be moved from TDC/TC to
MDL subsystem. Due to this, responsibility of LOCK_open is reduced. 
As the use of LOCK_open is removed in open_table() and 
mysql_rm_table() the above mentioned CYCLE does not form.
Revision ID for changes,
open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz
mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw
2012-05-17 18:07:59 +05:30
unknown
da5214831d Fix for bug lp:944706, task MDEV-193
The patch enables back constant subquery execution during
query optimization after it was disabled during the development
of MWL#89 (cost-based choice of IN-TO-EXISTS vs MATERIALIZATION).

The main idea is that constant subqueries are allowed to be executed
during optimization if their execution is not expensive.

The approach is as follows:
- Constant subqueries are recursively optimized in the beginning of
  JOIN::optimize of the outer query. This is done by the new method
  JOIN::optimize_constant_subqueries(). This is done so that the cost
  of executing these queries can be estimated.
- Optimization of the outer query proceeds normally. During this phase
  the optimizer may request execution of non-expensive constant subqueries.
  Each place where the optimizer may potentially execute an expensive
  expression is guarded with the predicate Item::is_expensive().
- The implementation of Item_subselect::is_expensive has been extended
  to use the number of examined rows (estimated by the optimizer) as a
  way to determine whether the subquery is expensive or not.
- The new system variable "expensive_subquery_limit" controls how many
  examined rows are considered to be not expensive. The default is 100.

In addition, multiple changes were needed to make this solution work
in the light of the changes made by MWL#89. These changes were needed
to fix various crashes and wrong results, and legacy bugs discovered
during development.
2012-05-17 13:46:05 +03:00
Sergey Petrunya
34e9a4c1e2 Merge of recent changes in MWL#182 in 5.3 with {Merge of MWL#182 with 5.5} 2012-05-17 00:59:03 +04:00
Sergey Petrunya
dfbd777fd8 MWL#182: SHOW EXPLAIN: Merge 5.3->5.5 2012-05-16 19:20:00 +04:00
Sergei Golubchik
431e042b5d c 2012-05-21 15:30:25 +02:00
Joerg Bruehe
5be07ceadd Merge 5.5.24 back into main 5.5.
This is a weave merge, but without any conflicts.
In 14 source files, the copyright year needed to be updated to 2012.
2012-05-07 22:20:42 +02:00
Joerg Bruehe
ad1e123f47 Merge 5.5.24 back into main 5.5.
This is a weave merge, but without any conflicts.
In 14 source files, the copyright year needed to be updated to 2012.
2012-05-07 22:20:42 +02:00
Sergey Petrunya
ff40705f89 Make SHOW EXPLAIN FOR produce a warning with the original text of query
that the EXPLAIN is for.
2012-04-26 08:48:31 +05:30
Sergey Petrunya
ca8aa3901c MWL#182: Explain running statements
- Code cleanup
2012-04-26 06:40:36 +05:30