An error occurred fetching the project authors.
- 13 Sep, 2007 1 commit
-
-
unknown authored
-
- 12 Sep, 2007 2 commits
- 10 Sep, 2007 1 commit
-
-
unknown authored
in get_index_for_order(), don't walk over the end of the index key parts when matching index description and needed ordering. mysql-test/r/delete.result: BUG#30385: Testcase mysql-test/t/delete.test: BUG#30385: Testcase
-
- 09 Sep, 2007 1 commit
-
-
unknown authored
"Rows not deleted from innodb partitioned tables if --innodb_autoinc_lock_mode=0" Due to a previous bugfix which initializes a previously uninitialized variable, ha_partition::get_auto_increment() may fail to operate correctly when the storage engine reports that it is only reserving one value and one or more partitions have a different 'next-value'. Currently, only affects Innodb's new-style auto-increment code which reserves larger blocks of values and has less inter-thread contention. mysql-test/suite/rpl/r/rpl_innodb_bug28430.result: Fix results - previous results shows symptoms of Bug30919 sql/ha_partition.cc: Bug30919 ha_partition::write_row() Do not insert a row if a failure occurred while generating auto-increment value. ha_partition::get_auto_increment() If there is an empty 'intersection' of auto-increment values, perform a second pass before failing because partitions may have different auto-increment 'next-value' attributes. storage/innobase/handler/ha_innodb.cc: Bug30919 Only set *first_value if it is less than autoinc value. This allows a higher value to be hinted when operating as a partitioned table. mysql-test/suite/rpl/r/rpl_innodb_bug30919.result: New BitKeeper file ``mysql-test/suite/rpl/r/rpl_innodb_bug30919.result'' mysql-test/suite/rpl/t/rpl_innodb_bug30919-master.opt: New BitKeeper file ``mysql-test/suite/rpl/t/rpl_innodb_bug30919-master.opt'' mysql-test/suite/rpl/t/rpl_innodb_bug30919.test: New BitKeeper file ``mysql-test/suite/rpl/t/rpl_innodb_bug30919.test''
-
- 07 Sep, 2007 3 commits
-
-
unknown authored
In the ha_partition::position() we don't calculate the number of the partition of the record, but use m_last_part value instead, relying on that it's previously set by some other call like ::write_row(). Delete_rows_log_event::do_exec_row() calls find_and_fetch_row(), where we used position() + rnd_pos() call for the InnoDB-based PARTITION-ed table as there HA_PRIMARY_KEY_REQUIRED_FOR_POSITION enabled. fixed by introducing new handler::rnd_pos_by_record() method to be used for random record-based positioning sql/ha_partition.cc: Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. ha_partition::rnd_pos_by_record() implemented sql/ha_partition.h: Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. ha_partition::rnd_pos_by_record() declared sql/handler.h: Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. handler::rnd_pos_by_record() introduced sql/log_event.cc: Bug #28430 Failure in replication of innodb partitioned tables on row/mixed format. handler::rnd_pos_by_record used instead of position() + rnd_pos() call
-
unknown authored
Initiate static const outside class definition server-tools/instance-manager/listener.cc: Initiate static const outside class definition server-tools/instance-manager/listener.h: Initiate static const outside class definition sql/ha_partition.cc: Initiate static const outside class definition sql/ha_partition.h: Initiate static const outside class definition
-
unknown authored
-
- 06 Sep, 2007 1 commit
-
-
unknown authored
Post-merge fix. sql/sql_parse.cc: Post-merge fix.
-
- 05 Sep, 2007 3 commits
-
-
unknown authored
-
unknown authored
- problem is the database name accessed in Rows_log_event write... get_db() which is a pointer to the share string... - point to table map instead? - or copy it? - or make sure that anything interacting with the share happens _after_ the epoch Problem with flush is that STMT_END_F may not be included as it shoudld...
-
unknown authored
this flush with flag TRUE causes spurious errors in the binlog... as it will insert a STMT_END_F... and hence an invalid binlog (missing table mappings)
-
- 04 Sep, 2007 1 commit
-
-
unknown authored
-
- 03 Sep, 2007 4 commits
-
-
unknown authored
-
unknown authored
DELETE FROM ... USING ... statements with the following type of ambiguous aliasing gave unexpected results: DELETE FROM t1 AS alias USING t1, t2 AS alias WHERE t1.a = alias.a; This query would leave table t1 intact but delete rows from t2. Fixed by changing DELETE FROM ... USING syntax so that only alias references (as opposed to alias declarations) may be used in FROM. mysql-test/r/delete.result: Bug#30234: Test Result mysql-test/t/delete.test: Bug#30234: Test Case sql/sql_yacc.yy: Bug#30234: - Added parser rule table_alias_ref_list that contains a list of table aliases only. - Added parser rule table_alias_ref that sets the TL_OPTION_ALIAS in order to turn off semantic checking that applies only for table names.
-
unknown authored
Invaldating a subset of a sufficiently large query cache can take a long time. During this time the server is efficiently frozen and no other operation can be executed. This patch addresses this problem by setting a time limit on how long time a dictionary access request can take before giving up on the attempt. This patch does not work for query cache invalidations issued by DROP, ALTER or RENAME TABLE operations. sql/sql_cache.cc: Changed mutex locking to a timed spinn lock. If access to query cache dictionary takes "a long time" (currently more than 0.1 seconds) the system fall backs on ordinary statement execution.
-
unknown authored
Use view db name as thread default database, in order to ensure that the view is parsed and prepared correctly. mysql-test/r/sp.result: test result mysql-test/t/sp.test: test case sql/sql_parse.cc: copy thd->db_length to table_list->db_length sql/sql_view.cc: Use view db name as thread default database, in order to ensure that the view is parsed and prepared correctly.
-
- 31 Aug, 2007 5 commits
-
-
unknown authored
-
unknown authored
of statement breaks binlog. There were two problems discovered by this bug: 1. Default (current) database is not fixed at the creation time. That leads to wrong output of DATABASE() function. 2. Database attributes (@@collation_database) are not fixed at the creation time. That leads to wrong resultset. Binlog breakage and Query Cache wrong output happened because of the first problem. The fix is to remember the current database at the PREPARE-time and set it each time at EXECUTE. mysql-test/include/query_cache_sql_prepare.inc: The first part of the test case for BUG#25843. mysql-test/r/query_cache_ps_no_prot.result: Update result file. mysql-test/r/query_cache_ps_ps_prot.result: Update result file. mysql-test/suite/rpl/r/rpl_ps.result: Update result file. mysql-test/suite/rpl/t/rpl_ps.test: The second part of the test case for BUG#25843. sql/mysql_priv.h: Added mysql_opt_change_db() prototype. sql/sp.cc: 1. Polishing; 2. sp_use_new_db() has been removed; 3. Use mysql_opt_change_db() instead of sp_use_new_db(). sql/sp.h: sp_use_new_db() has been removed. This function has nothing to do with a) sp and b) *new* database. It was merely "switch the current database if needed". sql/sp_head.cc: 1. Polishing. 2. Use mysql_opt_change_db() instead of sp_use_new_db(). sql/sql_class.cc: Move THD::{db, db_length} into Statement. sql/sql_class.h: Move THD::{db, db_length} into Statement. sql/sql_db.cc: Introduce mysql_opt_change_db() as a replacement (and inspired by) sp_use_new_db(). sql/sql_prepare.cc: 1. Remember the current database in Prepared_statement::prepare(). 2. Switch/restore the current database in Prepared_statement::execute().
-
unknown authored
When dumping database from a 4.x server, the mysqldump client inserted a delimiter sign inside special commentaries of the form: /*!... CREATE DATABASE IF NOT EXISTS ... ;*/ During restoration that dump file was splitten by delimiter signs on the client side, and the rest of some commentary strings was prepended to following statements. The 4x_server_emul test case option has been added for use with the DBUG_EXECUTE_IF debugging macro. This option affects debug server builds only to emulate particular behavior of a 4.x server for the mysqldump client testing. Non-debugging builds are not affected. mysql-test/r/mysqldump-compat.result: Added test case for bug #30126. mysql-test/t/mysqldump-compat.opt: Added test case for bug #30126. mysql-test/t/mysqldump-compat.test: Added test case for bug #30126. sql/sql_parse.cc: Fixed bug #30126. The mysqldump client uses the "SHOW CREATE DATABASE" query to obtain the "CREATE DATABASE" statement from that database. The 4.x server doesn't recognise that query, and mysqldump forms the "CREATE DATABASE" statement from scratch. That statement was formed incorrectly. To enforce the mysqldump client to create that statement from scratch, debugging code has been added to the mysql_execute_command function: in tcase of the --loose-debug=d,4x_server_emul option, the server returns parse error to client to emulate old behaviour. The 4x_server_emul test case option has been added for use with the DBUG_EXECUTE_IF debugging macro. This option affects debug server builds only to emulate particular behavior of a 4.x server for the mysqldump client testing. Non-debugging builds are not affected. client/mysqldump.c: Fixed bug #30126. The init_dumping_tables function has been modified to output semicolon outside of commentaries.
-
unknown authored
API instead. This is a pre-requisite of the fix for Bug 12713, which changes the data type of thd->ha_data from void * to struct Ha_data. include/mysql/plugin.h: Provide accessors to thd->ha_data for simple and robust code. sql/ha_ndbcluster_binlog.h: Use getters/setters of thd->ha_data, instead of direct access. sql/handler.cc: Use a getter of thd->ha_data instead of direct access. sql/log.cc: Use getters/setters of thd->ha_data, instead of direct access. sql/rpl_utility.h: Fix a compilation warning (declaration order must match initialization order in constructor). storage/federated/ha_federated.cc: Use interface accessors to thd->ha_data, instead of direct access.
-
unknown authored
Fix name of function in warning message. sql/item_timefunc.cc: Fix error message in extract_date_time(); ("str_to_time" -> "str_to_date")
-
- 30 Aug, 2007 6 commits
-
-
unknown authored
The problem is that a SELECT on one thread is blocked by INSERT ... ON DUPLICATE KEY UPDATE on another thread even when low_priority_updates is activated. The solution is to possibly downgrade the lock type to the setting of low_priority_updates if the INSERT cannot be concurrent. sql/sql_insert.cc: Possibly downgrade lock type to the the setting of low_priority_updates if if the INSERT cannot be concurrent.
-
unknown authored
comments) This change set is for 5.1 (manually merged) Before this fix, the server would accept queries that contained comments, even when the comments were not properly closed with a '*' '/' marker. For example, select 1 /* + 2 <EOF> would be accepted as select 1 /* + 2 */ <EOF> and executed as select 1 With this fix, the server now rejects queries with unclosed comments as syntax errors. Both regular comments ('/' '*') and special comments ('/' '*' '!') must be closed with '*' '/' to be parsed correctly. mysql-test/r/comments.result: Unbalanced comments are a syntax error. mysql-test/t/comments.test: Unbalanced comments are a syntax error. sql/sql_lex.cc: Unbalanced comments are a syntax error.
-
unknown authored
PREPARE and EXECUTE of statement breaks binlog. sql/sp.cc: - Polishing sp_use_new_db(): - renamed no_access_check to force_switch to be more adequate; - fixed comment; sql/sql_class.h: Polishing: fixed comment. sql/sql_db.cc: 1. Use mysql_change_db_impl() to reset current database instead of THD::set_db() in mysql_rm_db(). THD::set_db() does not take care of THD::db_access and database attributes (@@collation_database). 2. Polishing: add, fix comments.
-
unknown authored
sql/ha_ndbcluster.cc: Bug#20872 master*.err: miscellaneous error messages - only allocate share if fully successfull sql/ha_ndbcluster_binlog.cc: Bug#20872 master*.err: miscellaneous error messages - only allocate share if fully successfull - no need to print error, my_errno is set sql/ha_ndbcluster_binlog.h: Bug#20872 master*.err: miscellaneous error messages - only allocate share if fully successfull
-
unknown authored
sql/ha_ndbcluster.cc: remove warning for table exists in mysqld error log sql/ha_ndbcluster_binlog.cc: remove warning for table exists in mysqld error log
-
unknown authored
failures) Fixed open_performance_schema_table() and close_performance_schema_table() implementation and callers, to always execute balanced calls to: thd->reset_n_backup_open_tables_state(backup); thd->restore_backup_open_tables_state(backup); sql/log.cc: Balanced calls to reset_n_backup_open_tables_state() / restore_backup_open_tables_state() sql/sql_base.cc: Balanced calls to reset_n_backup_open_tables_state() / restore_backup_open_tables_state()
-
- 29 Aug, 2007 7 commits
-
-
unknown authored
mysql-test/t/query_cache.test: Disable query_cache test on embedded, due to bug 30710. sql/log_event_old.cc: Post-merge fix, change RELAY_LOG_INFO to Relay_log_info.
-
unknown authored
comments) Before this fix, the server would accept queries that contained comments, even when the comments were not properly closed with a '*' '/' marker. For example, select 1 /* + 2 <EOF> would be accepted as select 1 /* + 2 */ <EOF> and executed as select 1 With this fix, the server now rejects queries with unclosed comments as syntax errors. Both regular comments ('/' '*') and special comments ('/' '*' '!') must be closed with '*' '/' to be parsed correctly. mysql-test/r/comments.result: Unbalanced comments are a syntax error. mysql-test/t/comments.test: Unbalanced comments are a syntax error. sql/sql_lex.cc: Unbalanced comments are a syntax error.
-
unknown authored
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger Bug#17244 GRANT gives strange error message when used in a stored function GRANT/REVOKE statements are non-transactional (no explicit transaction boundaries) in nature and hence are forbidden inside stored functions and triggers, but they weren't being effectively forbidden. Furthermore, the absence of implict commits makes changes made by GRANT/REVOKE statements to not be rolled back. The implemented fix is to issue a implicit commit with every GRANT/REVOKE statement, effectively prohibiting these statements in stored functions and triggers. The implicit commit also fixes the replication bug, and looks like being in concert with the behavior of DDL and administrative statements. Since this is a incompatible change, the following sentence should be added to the Manual in the very end of the 3rd paragraph, subclause 13.4.3 "Statements That Cause an Implicit Commit": "Beginning with MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit." Patch contributed by Vladimir Shebordaev mysql-test/r/sp-error.result: Test case result for Bug#17244 mysql-test/t/sp-error.test: Test case for Bug#17244 sql/sp_head.cc: Set that a procedure with GRANT/REVOKE command has a (implicit or explicit) commit. sql/sql_parse.cc: End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively prohibit these statements in stored functions and triggers. An implicit commit also fixes a bug in replication, when GRANT or REVOKE would disappear from the binary log in case of a subsequent ROLLBACK, since they were considered transactional statements. mysql-test/suite/rpl/r/rpl_binlog_grant.result: Add test case result for Bug#21975 mysql-test/suite/rpl/t/rpl_binlog_grant.test: Add test case for Bug#21975
-
unknown authored
Removing unguarded read of slave_running field from inside terminate_slave_threads(). This could cause premature exit in the event that the slave thread already were shutting down, but isn't finished yet. The fields slave_running, io_thd, and sql_thread are guarded by an associated run_lock. A read of these fields were not guarded inside terminate_slave_threads(), which caused an assertion to fire. The assertion was removed, and the code reorganized slightly. sql/slave.cc: Changing signature of terminate_slave_thread() to accept a skip_lock parameter instead of two mutexes. This mimics the signature of the terminate_slave_threads() function. Code is also changed as a result of this. Removing unguarded check of slave_running field in the master info and relay log info structure since that could cause premature exit of terminate_slave_threads(). The thread variable for each of the slave threads can change before acquiring the run_lock mutex inside terminate_slave_thread(). Hence an assertion was removed that read the variable without guarding it with run_lock. Code that checked *slave_running status inside terminate_slave_thread() was reorganized slightly. sql/slave.h: Moving terminate_slave_thread() to use internal linkage.
-
unknown authored
The functions ROW_COUNT/FOUND_ROWS are indeed not safe to be used in statement based replication. Added code to declare them as such and switch the statement they're in to row based logging for mixed mode. sql/item_create.cc: Bug #30244: row_count/found_rows does not replicate well - add the functions to the set of "unsafe functions" for statement based replication mysql-test/suite/rpl/r/rpl_row_unsafe_funcs.result: BitKeeper file /home/kgeorge/mysql/work/B30244-5.1-opt/mysql-test/suite/rpl/r/rpl_row_unsafe_funcs.result mysql-test/suite/rpl/t/rpl_row_unsafe_funcs.test: BitKeeper file /home/kgeorge/mysql/work/B30244-5.1-opt/mysql-test/suite/rpl/t/rpl_row_unsafe_funcs.test
-
unknown authored
for bug 30377: use the function instead of the complex condition.
-
unknown authored
- reverting patch as there where unknows sideeffects that we do not have time to follow up on just now
-
- 28 Aug, 2007 5 commits
-
-
unknown authored
-
unknown authored
This is a performance bug, affecting in particular the bison generated code for the parser. Prior to this fix, the grammar used a long chain of reduces to parse an expression, like: bit_expr -> bit_term bit_term -> bit_factor bit_factor -> value_expr value_expr -> term term -> factor etc This chain of reduces cause the internal state automaton in the generated parser to execute more state transitions and more reduces, so that the generated MySQLParse() function would spend a lot of time looping to execute all the grammar reductions. With this patch, the grammar has been reorganized so that rules are more "flat", limiting the depth of reduces needed to parse <expr>. Tests have been written to enforce that relative priorities and properties of operators have not changed while changing the grammar. See the bug report for performance data. mysql-test/r/parser_precedence.result: Improved test coverage for operator precedence mysql-test/t/parser_precedence.test: Improved test coverage for operator precedence sql/sql_yacc.yy: Simplified the grammar to improve performances
-
unknown authored
The optimization that uses a unique index to remove GROUP BY did not ensure that the index was actually used, thus violating the ORDER BY that is implied by GROUP BY. Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains a unique index over non-nullable field(s). In case GROUP BY ... ORDER BY null is used, GROUP BY is simply removed. mysql-test/include/mix1.inc: Bug#30596: Test case for InnoDB Here, as opposed to for MyISAM, row lookup is done using index whenever the index covers the group list. mysql-test/r/distinct.result: Bug#30596: Changed test case. Prior to Bug#16458, These queries use temp table and filesort. The bug was that they used a temp table. However, that patch removed filesort also, in which case we can no longer gurantee correct ordering. mysql-test/r/group_by.result: Bug#30596: Correct result The test case for IGNORE INDEX FOR GROUP BY gets degraded performance (unneccesary filesort). This is due to Bug#30665, which will be fixed separately. mysql-test/r/innodb_mysql.result: Bug#30596: Test result mysql-test/t/group_by.test: Bug#30596: Test case sql/sql_select.cc: Bug#30596: The fix: - replace GROUP BY with ORDER BY unless ORDER BY [NULL|<constant>] - make sure to use the keys for GROUP BY in this ORDER BY.
-
unknown authored
Currently the Last_query_cost session status variable shows only the cost of a single flat subselect. For complex queries (with subselects or unions etc) Last_query_cost is not valid as it was showing the cost for the last optimized subselect. Fixed by reseting to zero Last_query_cost when the complete cost of the query cannot be determined. Last_query_cost will be non-zero only for single flat queries. mysql-test/r/status.result: Bug #30377: test case mysql-test/t/status.test: Bug #30377: test case sql/sql_lex.h: Bug #30377: helper function sql/sql_select.cc: Bug #30377: don't assign cost if not on single level statement
-
unknown authored
- the listed file_names are not necessarily on disk, so we need to discover them if they aren't mysql-test/t/ndb_restore.test: Bug #30667 ndb table discovery does not work correcly with information schema
-