Commit graph

7937 commits

Author SHA1 Message Date
Bill Qu
5693b1e4a4 Bug #15868071 USING SET GLOBAL SQL_LOG_BIN SHOULD NOT BE ALLOWED
Normally, SET SESSION SQL_LOG_BIN is used by DBAs to run a
non-conflicting command locally only, ensuring it does not
get replicated.
Setting GLOBAL SQL_LOG_BIN would not require all sessions to
disconnect. When SQL_LOG_BIN is changed globally, it does not
immediately take effect for any sessions. It takes effect by
becoming the session-level default inherited at the start of
each new session, and this setting is kept and cached for the
duration of that session. Setting it intentionally is unlikely
to have a useful effect under any circumstance; setting it
unintentionally, such as while intending to use SET [SESSION]
is potentially disastrous. Accidentally using SET GLOBAL
SQL_LOG_BIN will not show an immediate effect to the user,
instead not having the desired session-level effect, and thus
causing other potential problems with local-only maintenance
being binlogged and executed on slaves; And transactions from
new sessions (after SQL_LOG_BIN is changed globally) are not
binlogged and replicated, which would result in irrecoverable
or difficult data loss.
This is the regular GLOBAL variables way to work, but in
replication context it does not look right on a working server
(with connected sessions) 'set global sql_log_bin' and none of
that connections is affected. Unexperienced DBA after noticing
that the command did "nothing" will change the session var and
most probably won't unset the global var, causing new sessions
to not be binlog.
Setting GLOBAL SQL_LOG_BIN allows DBA to stop binlogging on all
new sessions, which can be used to make a server "replication
read-only" without restarting the server. But this has such big
requirements, stop all existing connections, that it is more
likely to make a mess, it is too risky to allow the GLOBAL variable.

The statement 'SET GLOBAL SQL_LOG_BIN=N' will produce an error
in 5.5, 5.6 and 5.7. Reading the GLOBAL SQL_LOG_BIN will produce
a deprecation warning in 5.7.
2014-09-24 09:44:48 +08:00
unknown
0e5fe8e412 Merge from mysql-5.5.40-release 2014-09-23 08:51:23 +02:00
murthy.narkedimilli@oracle.com
abb9945965 Merge from mysql-5.5.40-release 2014-09-23 08:51:23 +02:00
Annamalai Gurusami
b8c9d93bf3 Bug #19306524 FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION

Scenario:

In a stored procedure, CREATE TABLE statement is not allowed.  But an
exception is provided for CREATE TEMPORARY TABLE.  We can create a temporary
table in a stored procedure.

Let there be two stored functions f1 and f2 and two stored procedures p1 and
p2.  Their properties are as follows:

. stored function f1() calls stored procedure p1().
. stored function f2() calls stored procedure p2().
. stored procedure p1() creates temporary table t1.
. stored procedure p2() does DML on t1.

Consider the following situation:

1.  Autocommit mode is on. 
2.  select f1()
3.  select f2()

Step 2:  In this step, t1 would be created via p1().  A table level transaction
lock would have been taken.  The ::external_lock() would not have been called
on this table.  At the end of step 2, because of autocommit mode on, this table
level lock will be released.

Step 3:  When we execute DML on table t1 via p2() we have two problems:

Problem 1:

The function ha_innobase::external_lock() would have been called but since
it is a select query no table level locks would have been taken.  Hence the
following assert will fail:

ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX));

Solution:

The solution would be to identify this situation and take a table level lock
and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML
operations.

Problem 2:

Another problem is that in step 3, ha_innobase::open() is never called on
the table t1.  

Solution:

The solution would be to identify this situation and call re-init the handler
of table t1.

rb#6429 approved by Krunal.
2014-09-18 15:17:39 +05:30
Annamalai Gurusami
db78f29b31 Bug #19306524 FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION

Scenario:

In a stored procedure, CREATE TABLE statement is not allowed.  But an
exception is provided for CREATE TEMPORARY TABLE.  We can create a temporary
table in a stored procedure.

Let there be two stored functions f1 and f2 and two stored procedures p1 and
p2.  Their properties are as follows:

. stored function f1() calls stored procedure p1().
. stored function f2() calls stored procedure p2().
. stored procedure p1() creates temporary table t1.
. stored procedure p2() does DML on t1.

Consider the following situation:

1.  Autocommit mode is on. 
2.  select f1()
3.  select f2()

Step 2:  In this step, t1 would be created via p1().  A table level transaction
lock would have been taken.  The ::external_lock() would not have been called
on this table.  At the end of step 2, because of autocommit mode on, this table
level lock will be released.

Step 3:  When we execute DML on table t1 via p2() we have two problems:

Problem 1:

The function ha_innobase::external_lock() would have been called but since
it is a select query no table level locks would have been taken.  Hence the
following assert will fail:

ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX));

Solution:

The solution would be to identify this situation and take a table level lock
and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML
operations.

Problem 2:

Another problem is that in step 3, ha_innobase::open() is never called on
the table t1.  

Solution:

The solution would be to identify this situation and call re-init the handler
of table t1.

rb#6429 approved by Krunal.
2014-09-18 15:17:39 +05:30
Nirbhay Choubey
9a0566b09b MDEV-6447: Galera: Enable QC
* Added galera/query_cache test
* Merged patch for lp:1296403
2014-09-17 14:12:00 -04:00
Annamalai Gurusami
40f30ee6cc Bug #17852083 PRINT A WARNING WHEN DDL HAS AN ERROR IN INNODB_STRICT_MODE = 1
Problem:

Creation of a table fails when innodb_strict_mode is enabled, but the same
table is created without any warning when innodb_strict_mode is enabled.

Solution:

If creation of a table fails with an error when innodb_strict_mode is
enabled, it must issue a warning when innodb_strict_mode is disabled.

rb#6723 approved by Krunal.
2014-09-17 10:42:31 +05:30
Annamalai Gurusami
44fd241a22 Bug #17852083 PRINT A WARNING WHEN DDL HAS AN ERROR IN INNODB_STRICT_MODE = 1
Problem:

Creation of a table fails when innodb_strict_mode is enabled, but the same
table is created without any warning when innodb_strict_mode is enabled.

Solution:

If creation of a table fails with an error when innodb_strict_mode is
enabled, it must issue a warning when innodb_strict_mode is disabled.

rb#6723 approved by Krunal.
2014-09-17 10:42:31 +05:30
Rich Prohaska
52030b5971 DB-720 run the cluster key partition test on mariadb 2014-09-15 14:08:50 -04:00
Rich Prohaska
8978487477 DB-714 read free replication 2014-09-15 07:47:43 -04:00
Rich Prohaska
3c64729c89 DB-720 test case for clustering keys on partitioned tokudb tables 2014-09-15 07:27:18 -04:00
Rich Prohaska
7b061ff6a3 DB-504 redo bulk fetch select tests in partitioned tables 2014-09-13 16:06:55 -04:00
Nirbhay Choubey
be055b3835 Minor improvements in mtr and wsrep test files. 2014-09-09 19:05:25 -04:00
Nirbhay Choubey
e5267cae8a MDEV-6717 : wsrep_data_home_dir should default to @@datadir
Used mysql_real_data_home as wsrep_data_home_dir's default.
Added a test case.
2014-09-09 13:41:22 -04:00
Nirbhay Choubey
140fd7adbd MDEV-6699 : wsrep_node_name not automatically set to hostname
Fixed by using hostname (glob_hostname) as default value for
wsrep_node_name system variable.
Added a test case.
2014-09-09 09:18:35 -04:00
Murthy Narkedimilli
3139aa87b4 Adding patch for security bug 19471516 2014-09-08 11:33:55 +02:00
Murthy Narkedimilli
a2375bdbe0 Adding patch for security bug 19471516 2014-09-08 11:33:55 +02:00
Rich Prohaska
f1dc0a9671 DB-310 run tokudb_support_xa.test on mysql and mariadb 5.5 2014-09-05 09:49:27 -04:00
BohuTANG
856dd95b71 DB-310 add tokudb_support_xa variable
this variable scope is Global, Session
type is boolean and default value is TRUE
2014-09-05 13:17:54 +08:00
Jan Lindström
9e63cc0780 MDEV-6651: MariaDB galera cluster crashes in file row0mysql.cc line 684
DELETE FROM ports WHERE ports.id = 'f37aa3fe-ab99-4d0f-a566-6cd3169d7516'
where table ports have foreign keys.

Verified that current 5.5-galera is not affected and added test case
to regression set.
2014-09-03 18:51:02 +03:00
Rich Prohaska
613b729ae9 DB-718 test case for broken error handling in tokudb_fractal_tree_info info schema plugin 2014-09-03 08:13:49 -04:00
Jan Lindström
454037b794 MDEV-6682 innodb.innodb_simulate_comp_failures_small is too slow
if it's run on a real disk
  
  Made test smaller.
2014-09-03 07:37:13 +03:00
Rich Prohaska
9b4e15d50c DB-712 fix tokudb locks info schema test results due to new schema 2014-08-28 15:11:55 -04:00
Rich Prohaska
4f45481eb2 DB-713 separate some long running tokudb tests so that valgrind runs without --big-test can exclude them 2014-08-27 18:00:19 -04:00
Nirbhay Choubey
bc59e4c17f Switched wsrep_causal_reads ON for galera test suite. 2014-08-26 16:14:46 -04:00
Annamalai Gurusami
2f8bd757cd Bug #19471516 SERVER CRASHES WHEN EXECUTING ALTER TABLE ADD FOREIGN KEY
Problem:

We maintain two rb trees in each dict_table_t.  The foreign_rbt must be in
sync with foreign_list.  The referenced_rbt must be in sync with
referenced_list. There is one function which checks this consistency and it
failed, resulting in an assert failure.

The root cause of the problem was identified that the search order was 
lost in the referenced_rbt.  This is because while renaming the table,
we didn't not refresh this referenced_rbt.

Solution:

When a foreign key is renamed, we must delete and re-insert into both
foreign_rbt and referenced_rbt.  

rb#6412 approved by Jimmy.
2014-08-25 16:25:07 +02:00
Annamalai Gurusami
f97dfa81a5 Bug #19471516 SERVER CRASHES WHEN EXECUTING ALTER TABLE ADD FOREIGN KEY
Problem:

We maintain two rb trees in each dict_table_t.  The foreign_rbt must be in
sync with foreign_list.  The referenced_rbt must be in sync with
referenced_list. There is one function which checks this consistency and it
failed, resulting in an assert failure.

The root cause of the problem was identified that the search order was 
lost in the referenced_rbt.  This is because while renaming the table,
we didn't not refresh this referenced_rbt.

Solution:

When a foreign key is renamed, we must delete and re-insert into both
foreign_rbt and referenced_rbt.  

rb#6412 approved by Jimmy.
2014-08-25 16:25:07 +02:00
Rich Prohaska
f90c40ef73 DB-504 test replace select triggers for bulk fetch 2014-08-18 15:58:49 -04:00
Rich Prohaska
c92be4c8b5 DB-504 move bulk fetch tests 2014-08-18 15:57:12 -04:00
Rich Prohaska
945ffb2f10 DB-504 test insert select with various triggers to make sure that bulk fetch will work 2014-08-18 14:45:39 -04:00
Rich Prohaska
56126798a8 DB-500 allow simple deletes to use bulk fetch 2014-08-18 13:38:51 -04:00
Nirbhay Choubey
dc0f1864ae Fix for binlog tests. 2014-08-15 18:41:36 -04:00
Nirbhay Choubey
a2d5a54374 Added a basic test for wsrep_sync_wait system variable.
Also made some coding style related changes.
2014-08-13 10:39:01 -04:00
Kristian Nielsen
f2cbca793c Change a couple of permissions that cause lintian warnings in .deb packaging and don't really hurt to fix. 2014-08-13 15:46:39 +02:00
Jan Lindström
9dc738bf5f MDEV-6546: innodb.innodb_simulate_comp_failures_small fails
sporadically

Fix: Modify test to be smaller so that testcase timeout does not
trigger. We already have a test for --big-test setup
(innodb.innodb_simulate_comp_failures).
2014-08-13 09:37:12 +03:00
joel9001
c2f39e80e0 #268 Adding bulk fetch MTR test and result files 2014-08-12 16:03:34 -04:00
Nirbhay Choubey
e1facda416 Fix for some failing tests. 2014-08-11 17:09:59 -04:00
Rich Prohaska
89d33f7e49 Tokutek/mariadb-5.5#71 run part_index_scan on mariadb 2014-08-11 16:46:06 -04:00
Nirbhay Choubey
ec91eea8db Local merge of mariadb-5.5.39
bzr merge -r4264 maria/5.5

Text conflict in sql/mysqld.cc
Text conflict in storage/xtradb/btr/btr0cur.c
Text conflict in storage/xtradb/buf/buf0buf.c
Text conflict in storage/xtradb/buf/buf0lru.c
Text conflict in storage/xtradb/handler/ha_innodb.cc
5 conflicts encountered.
2014-08-06 14:06:11 -04:00
Sergei Golubchik
50e192a04f Bug#17638477 UNINSTALL AND INSTALL SEMI-SYNC PLUGIN CAUSES SLAVES TO BREAK
Fix the bug properly (plugin cannot be unloaded as long as it's locked).
Enable and fix the test case.
Significantly reduce number of LOCK_plugin locks for semisync
(practically all locks were removed)
2014-08-03 12:45:14 +02:00
Sergei Golubchik
1c6ad62a26 mysql-5.5.39 merge
~40% bugfixed(*) applied
~40$ bugfixed reverted (incorrect or we're not buggy)
~20% bugfixed applied, despite us being not buggy
(*) only changes in the server code, e.g. not cmakefiles
2014-08-02 21:26:16 +02:00
Sergei Golubchik
4b4de01fae 5.3 merge 2014-08-01 16:51:12 +02:00
Jan Lindström
d8a9bb4585 Add missing results file. 2014-08-01 14:33:49 +03:00
Michael Widenius
5364315229 Fix for MDEV-6493: Assertion `table->file->stats.records > 0 || error' failure, or 'Invalid write' valgrind warnings, or crash on scenario with Aria table, view, LOCK TABLES
This bug only happens in case of paritioned tables used in LOCK TABLES and implicit_commit() was called
(as part of trying to execute a CREATE TABLE withing lock tables)

The problem was that Aria could not move the tables from one transaction to the new one, as thd->open_tables contained
a partitioned tables and not an Aria table.

Fix:
- Store a list of all open tables that are part of a share in share->open_tables
- In maria::implict_commit() use transaction->used_tables & share->open_tables to find out which tables
  was part of the current transaction instead of using thd->open_tables, which may contain partitioned tables.


mysql-test/suite/maria/maria_partition.result:
  Added test case
mysql-test/suite/maria/maria_partition.test:
  Added test case
storage/maria/ha_maria.cc:
  Use trn->used tables and share->open_tables to find out which tables was part of the current transaction instead of using thd->open_tables.
storage/maria/ma_close.c:
  Remove closed table from share->open_list
storage/maria/ma_open.c:
  Add table to share->open_list
storage/maria/ma_state.c:
  Added comment
storage/maria/maria_def.h:
  Added share->open_list, a list of all tables that is using this share.
2014-07-30 13:27:52 +03:00
Elena Stepanova
0aa40c35ca MDEV-6378 mtr engines iuds time tests fail
- adjusted a test result according to the change made for MDEV-6100;
- added explicit timezone for engines/iuds, since MTR in
  MariaDB does not set it like MySQL's, and tests with constant TIMESTAMP
  can have different outcome
2014-07-28 13:31:46 +04:00
Rich Prohaska
0cfbaccf64 #261 run multiple queries in part_index_scan 2014-07-23 13:50:34 -04:00
Sergei Golubchik
4e6e720160 MDEV-6290 Crash in KILL HARD QUERY USER x@y when slave threads are running
KILL USER should ignore system threads where sctx->user=sctx->host=NULL
2014-07-23 19:36:15 +02:00
Rich Prohaska
b196bddb59 #267 fix mdev5932 test and result 2014-07-23 10:00:13 -04:00
Sergei Golubchik
1907bf042a MDEV-6409 CREATE VIEW replication problem if error occurs in mysql_register_view
fix by Sriram Patil
2014-07-23 12:01:05 +02:00
Rich Prohaska
db8a35c03d #261 Tokutek/mariadb-5.5#69 run part_index_scan test on mariadb 2014-07-22 11:03:08 -04:00