- 12 Dec, 2007 1 commit
-
-
unknown authored
The problem is that some DDL statements (ALTER TABLE, CREATE TRIGGER, FLUSH TABLES, ...) when under LOCK TABLES need to momentarily drop the lock, reopen the table and grab the write lock again (using reopen_tables). When grabbing the lock again, reopen_tables doesn't pass a flag to mysql_lock_tables in order to ignore the impending global read lock, which causes a assertion because LOCK_open is being hold. Also dropping the lock must not signal to any threads that the table has been relinquished (related to the locking/flushing protocol). The solution is to correct the way the table is reopenned and the locks grabbed. When reopening the table and under LOCK TABLES, the table version should be set to 0 so other threads have to wait for the table. When grabbing the lock, any other flush should be ignored because it's theoretically a atomic operation. The chosen solution also fixes a potential discrepancy between binlog and GRL (global read lock) because table placeholders were being ignored, now a FLUSH TABLES WITH READ LOCK will properly for table with open placeholders. It's also important to mention that this patch doesn't fix a potential deadlock if one uses two GRLs under LOCK TABLES concurrently. mysql-test/r/lock_multi.result: Add test case result for Bug#32395 mysql-test/r/trigger_notembedded.result: Add test case result for Bug#32395 mysql-test/t/lock_multi.test: Add test case for Bug#32395 mysql-test/t/trigger_notembedded.test: Enable test case for Bug#32395 sql/ha_ndbcluster.cc: Update close_cached_tables usage. sql/ha_ndbcluster_binlog.cc: Update close_cached_tables usage. sql/mysql_priv.h: Update close_cache_tables prototype. sql/set_var.cc: Update close_cached_tables usage and set flag to wait for tables with placeholders. This is one of the places where a GRL can be obtained. sql/sql_base.cc: Preserve old version for write locked tables and ignore pending flushes and update close_cache_tables to take into account name locked tables. sql/sql_parse.cc: Update close_cached_tables usage and pass flag so that name locked tables are waited for. sql/sql_table.cc: Protect the table against a impending GRL if under LOCK TABLES.
-
- 10 Dec, 2007 5 commits
-
-
unknown authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime mysql-test/r/read_only.result: Auto merged sql/sql_parse.cc: Auto merged mysql-test/t/read_only.test: Manual merge
-
unknown authored
mysql-test/r/read_only.result: Removing non deterministic test results from test. mysql-test/t/read_only.test: Removing non deterministic test results from test.
-
unknown authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime sql/sql_parse.cc: Auto merged
-
unknown authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime sql/sql_parse.cc: Auto merged
-
unknown authored
into adventure.(none):/home/thek/Development/cpp/bug27440/my51-bug27440 mysql-test/r/read_only.result: Manual merge mysql-test/t/read_only.test: Manual merge sql/sql_parse.cc: Manual merge
-
- 07 Dec, 2007 1 commit
-
-
unknown authored
When read_only option was enabled, a user without SUPER privilege could perform CREATE DATABASE and DROP DATABASE operations. This patch adds a check to make sure this isn't possible. It also attempts to simplify the logic used to determine if relevant tables are updated, making it more human readable. mysql-test/r/read_only.result: Updated result file mysql-test/t/read_only.test: A test case is added which shows that it is not possible to drop or create a database in read-only mode despite having the GRANT permissions to do so, SUPER user excepted. sql/sql_parse.cc: - Simplified complex predicate by grouping it in a read friendly way. - Added predicate to fail on database updates while running in read-only mode.
-
- 05 Dec, 2007 2 commits
- 04 Dec, 2007 2 commits
- 30 Nov, 2007 6 commits
-
-
unknown authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
unknown authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime
-
unknown authored
The problem was that THD::killed was reset after a command was read from the socket, but before it was actually handled. That lead to a race: if another KILL statement was issued for this connection in the middle of reading from the socket and processing a command, THD::killed state would be cleaned. The fix is to move this cleanup into net_send_error() function. A sample test case exists in binlog_killed.test: - connection 1: start a new transaction on table t1; - connection 2: send query to the server (w/o waiting for the result) to update data in table t1 -- this query will be blocked since there is unfinished transaction; - connection 1: kill query in connection 2 and finish the transaction; - connection 2: get result of the previous query -- it should be the "query-killed" error. This test however contains race condition, which can not be fixed with the current protocol: there is no way to guarantee, that the server will receive and start processing the query in connection 2 (which is intended to get blocked) before the KILL command (sent in the connection 1) will arrive. In other words, there is no way to ensure that the following sequence will not happen: - connection 1: start a new transaction on table t1; - connection 1: kill query in connection 2 and finish the transaction; - connection 2: send query to the server (w/o waiting for the result) to update data in table t1 -- this query will be blocked since there is unfinished transaction; - connection 2: get result of the previous query -- the query will succeed. So, there is no test case for this bug, since it's impossible to write a reliable test case under the current circumstances. sql/protocol.cc: Move thd->killed cleanup from dispatch_command() to net_send_error(). sql/sql_parse.cc: Move thd->killed cleanup from dispatch_command() to net_send_error().
-
unknown authored
Enabling the test case. mysql-test/t/disabled.def: Enable grant3.test.
-
unknown authored
Parser rejects valid INTERVAL() expressions when associated with arithmetic operators. The problem is the way in which the expression and interval grammar rules were organized caused shift/reduce conflicts. The solution is to tweak the interval rules to avoid shift/reduce conflicts by removing the broken interval_expr rule and explicitly specify it's content where necessary. Original fix by Davi Arnaut, revised and improved rules by Marc Alff mysql-test/r/parser.result: Add test case result for Bug#22312 mysql-test/t/parser.test: Add test case for Bug#22312 sql/sql_yacc.yy: Resolve shift/reduce conflicts by reorganizing the interval expression rules.
-
unknown authored
The following clarification should be made in The Manual: Standard SQL is quite clear that, if new columns are added to a table after a view on that table is created with "select *", the new columns will not become part of the view. In all cases, the view definition (view structure) is frozen at CREATE time, so changes to the underlying tables do not affect the view structure. mysql-test/r/view.result: Update result file. mysql-test/t/view.test: Add a test case for BUG#26676: VIEW using old table schema in a session.
-
- 29 Nov, 2007 1 commit
-
-
unknown authored
This bug is actually two bugs in one, one of which is CREATE TRIGGER under LOCK TABLES and the other is CREATE TRIGGER under LOCK TABLES simultaneous to a FLUSH TABLES WITH READ LOCK (global read lock). Both situations could lead to a server crash or deadlock. The first problem arises from the fact that when under LOCK TABLES, if the table is in the set of locked tables, the table is already open and it doesn't need to be reopened (not a placeholder). Also in this case, if the table is not write locked, a exclusive lock can't be acquired because of a possible deadlock with another thread also holding a (read) lock on the table. The second issue arises from the fact that one should never wait for a global read lock if it's holding any locked tables, because the global read lock is waiting for these tables and this leads to a circular wait deadlock. The solution for the first case is to check if the table is write locked and upgraded the write lock to a exclusive lock and fail otherwise for non write locked tables. Grabbin the exclusive lock in this case also means to ensure that the table is opened only by the calling thread. The second issue is partly fixed by not waiting for the global read lock if the thread is holding any locked tables. The second issue is only partly addressed in this patch because it turned out to be much wider and also affects other DDL statements. Reported as Bug#32395 mysql-test/r/trigger.result: Add test case result for Bug#23713 mysql-test/r/trigger_notembedded.result: Add test case result for Bug#23713 mysql-test/t/trigger.test: Add test case for Bug#23713 mysql-test/t/trigger_notembedded.test: Add test case for Bug#23713 sql/mysql_priv.h: Locally export wait_while_table_is_used and name_lock_locked_table and add flag to mysql_ha_rm_tables to signal that LOCK_open is locked. sql/sql_base.cc: Introduce name_lock_locked_table function and match close_old_data_files function declaration and definition. sql/sql_handler.cc: Add flag to mysql_ha_rm_tables to signal that LOCK_open is locked. sql/sql_rename.cc: Fix mysql_ha_rm_tables caller. sql/sql_table.cc: Export wait_while_table_is_used and assert that LOCK_open is locked and fix mysql_ha_rm_tables caller. sql/sql_trigger.cc: Upgrade write locked tables to a exclusive lock and fail if the table is not write locked. Also, don't wait for the global read lock if under LOCK TABLES.
-
- 28 Nov, 2007 13 commits
-
-
unknown authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge sql/item_func.cc: Auto merged sql/mysqld.cc: Auto merged sql/sp_head.cc: Auto merged sql/sql_parse.cc: Auto merged sql-common/client.c: Auto merged sql/sql_yacc.yy: Auto merged
-
unknown authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge sql/sql_table.cc: Auto merged
-
unknown authored
-
unknown authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge sql/events.cc: Auto merged sql/item_func.cc: Auto merged sql/mysql_priv.h: Auto merged sql/mysqld.cc: Auto merged sql/sql_acl.cc: Auto merged sql/sql_base.cc: Auto merged sql/sql_lex.h: Auto merged sql/sql_parse.cc: Auto merged sql/sql_yacc.yy: Auto merged sql/sql_table.cc: manual merge
-
unknown authored
into mysql.com:/Users/davi/mysql/mysql-5.1-runtime mysql-test/r/lock_multi.result: Null merge. mysql-test/t/lock_multi.test: Null merge. sql/sql_table.cc: Null merge.
-
unknown authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge sql/sql_yacc.yy: Auto merged sql-common/client.c: Auto merged
-
unknown authored
into mysql.com:/Users/davi/mysql/mysql-5.0-runtime
-
unknown authored
Kill of a CREATE TABLE source_table LIKE statement waiting for a name-lock on the source table causes a bad lock interaction. The mysql_create_like_table() has a bug that if the connection is killed while waiting for the name-lock on the source table, it will jump to the wrong error path and try to unlock the source table and LOCK_open, but both weren't locked. The solution is to simple return when the name lock request is killed, it's safe to do so because no lock was acquired and no cleanup is needed. Original bug report also contains description of other problems related to this scenario but they either already fixed in 5.1 or will be addressed separately (see bug report for details). mysql-test/r/lock_multi.result: Add test case result for Bug#31479 mysql-test/t/lock_multi.test: Add test case for Bug#31479 sql/sql_table.cc: Rerturn TRUE when the lock gets killed.
-
unknown authored
into stella.local:/home2/mydev/mysql-5.1-axmrg mysql-test/t/disabled.def: Manual merge from 5.0.
-
unknown authored
Moved disabling to rpl suite. Bug#32801 wait_timeout.test fails randomly Disabled test case. mysql-test/suite/rpl/t/disabled.def: Bug#8693 Test 'rpl_log_pos' fails sometimes Moved disabling to rpl suite.
-
unknown authored
Disabled test case.
-
unknown authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.1-runtime
-
unknown authored
-
- 27 Nov, 2007 9 commits
-
-
unknown authored
into stella.local:/home2/mydev/mysql-5.1-axmrg client/mysql.cc: Auto merged mysql-test/r/archive.result: Auto merged mysql-test/r/ctype_ucs.result: Auto merged mysql-test/t/archive.test: Auto merged mysql-test/t/ctype_uca.test: Auto merged mysql-test/t/ctype_ucs.test: Auto merged sql/item_cmpfunc.cc: Auto merged sql/mysqld.cc: Auto merged sql/sql_class.h: Auto merged mysql-test/t/disabled.def: Manual merge from 5.0 mysql-test/t/subselect.test: Manual merge from 5.0
-
unknown authored
into stella.local:/home2/mydev/mysql-5.1-axmrg include/my_base.h: Auto merged mysql-test/mysql-test-run.pl: Auto merged mysql-test/suite/ndb/t/disabled.def: Auto merged mysql-test/t/partition.test: Auto merged sql/handler.cc: Auto merged sql/item_cmpfunc.cc: Auto merged sql/slave.cc: Auto merged sql/sql_insert.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_table.cc: Auto merged sql/sql_yacc.yy: Auto merged client/mysql.cc: Manual merge mysql-test/suite/rpl/t/disabled.def: Manual merge
-
unknown authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
unknown authored
-
unknown authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
unknown authored
Disabled the test case.
-
unknown authored
into mysql.com:/home/ram/work/b30495/b30495.5.0
-
unknown authored
into lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge sql/mysqld.cc: Auto merged sql/sp_head.cc: Auto merged sql/sql_class.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_table.cc: Auto merged sql/sql_yacc.yy: Auto merged
-
unknown authored
into mysql.com:/home/ram/work/b30495/b30495.5.1
-