An error occurred fetching the project authors.
- 30 Sep, 2009 7 commits
-
-
Kristofer Pettersson authored
-
Jonathan Perkin authored
-
Jonathan Perkin authored
Copy mysql-stress-run.pl into noinstall package.
-
Kristofer Pettersson authored
'flush tables' crashes The server crashes when 'show procedure status' and 'flush tables' are run concurrently. This is caused by the way mysql.proc table is added twice to the list of table to lock although the requirements on the current locking API assumes differently. No test case is submitted because of the nature of the crash which is currently difficult to reproduce in a deterministic way. This is a backport from 5.1 myisam/mi_dbug.c: * check_table_is_closed is only used in EXTRA_DEBUG mode but since it is iterating over myisam shared data it still needs to be protected by an appropriate mutex. sql/sql_yacc.yy: * Since the I_S mechanism is already handling the open and close of mysql.proc there is no need for the method sp_add_to_query_tables.
-
Martin Hansson authored
-
unknown authored
The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the database is not selected by --database option of mysqlbinlog command. This can result in problem if there are some statements in the transaction are not filtered out. To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' in regardless of the database filtering rules. client/mysqlbinlog.cc: Skip the database check for BEGIN/COMMIT/ROLLBACK log events. mysql-test/r/mysqlbinlog.result: Test result for bug#46998 mysql-test/suite/binlog/t/binlog_row_mysqlbinlog_db_filter.test: The test case is updated duo to the patch of bug#46998 mysql-test/t/mysqlbinlog.test: Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output in regardless of database filtering
-
unknown authored
The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the database is not selected by --database option of mysqlbinlog command. This can result in problem if there are some statements in the transaction are not filtered out. To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' in regardless of the database filtering rules. client/mysqlbinlog.cc: Skip the database check for BEGIN/COMMIT/ROLLBACK log events. mysql-test/r/mysqlbinlog.result: Test result for bug#46998 mysql-test/t/mysqlbinlog.test: Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output in regardless of database filtering
-
- 29 Sep, 2009 14 commits
-
-
Tatiana A. Nurnberg authored
-
Kristofer Pettersson authored
-
Tatiana A. Nurnberg authored
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
replication MySQL server uses wrong lock type (always TL_READ instead of TL_READ_NO_INSERT when appropriate) for tables used in subqueries of UPDATE statement. This leads in some cases to a broken replication as statements are written in the wrong order to the binlog. sql/sql_yacc.yy: * Set lock_option to either TL_READ_NO_INSERT or TL_READ for any sub-SELECT following UPDATE. * Changed line adjusted for parser identation rules; code begins at column 13.
-
Martin Hansson authored
-
Alexey Botchkov authored
-
Davi Arnaut authored
can be interpreted as a shell metacharacter in some circumstances. For example, it is interpreted as a command separator when invoking a debugger. mysql-test/lib/mtr_cases.pm: Use ':' as the separator on non-Windows platforms. mysql-test/mysql-test-run.pl: Remove unnecessary use of the separator.
-
Alexey Botchkov authored
-
Tatiana A. Nurnberg authored
-
Alexey Botchkov authored
-
Davi Arnaut authored
The problem was that appending values to the end of an existing ENUM or SET column was being treated as table data modification, preventing a immediately (fast) table alteration that occurs when only table metadata is being modified. The cause was twofold: adding a enumeration or set members to the end of the list of valid member values was not being considered a "compatible" table alteration, and for SET columns, the check was being done upon the max display length and not the underlying (pack) length of the field. The solution is to augment the function that checks wether two ENUM or SET fields are compatible -- by comparing the pack lengths and performing a limited comparison of the member values. mysql-test/r/alter_table.result: Add test case result for Bug#45567 mysql-test/t/alter_table.test: Add test case for Bug#45567 sql/field.cc: Check whether two fields can be considered 'equal' for table alteration purposes. Fields are equal if they retain the same pack length and if new members are added to the end of the list. sql/field.h: Add comment and remove method.
-
Mattias Jonsson authored
-
Sergey Glukhov authored
The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed. mysql-test/r/join.result: test result mysql-test/t/join.test: test case sql/item.cc: The bug is not related to MERGE table or TRIGGER. More correct description would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'. On PREPARE stage(see test case) we call mark_common_columns() func which creates ON condition for NATURAL JOIN and sets appropriate table read_set bitmaps for fields which are used in ON condition. On EXECUTE stage mark_common_columns() is not called, we set necessary read_set bitmaps in setup_conds(). But 'B.f1' field is already processed and related item alredy fixed before setup_conds() as updated field and setup_conds can not set read_set bitmap because of that. The fix is to set read_set bitmap for appropriate table field even if Item_direct_view_ref item which represents a refernce to this field is fixed.
-
- 28 Sep, 2009 13 commits
-
-
Jonathan Perkin authored
-
Jonathan Perkin authored
-
Jonathan Perkin authored
Add --help option.
-
Georgi Kodinov authored
by Svoj over e-mail.
-
Georgi Kodinov authored
-
Magnus Blåudd authored
-
Tatiana A. Nurnberg authored
"load data" statements were written to the binlog as a mix of the original statement and bits recreated from parse-info. This relied on implementation details and broke with IGNORE_SPACES and versioned comments. We now completely resynthesize the query for LOAD DATA for binlog (which among other things normalizes them somewhat with regard to case, spaces, etc.). We have already parsed the query properly, so we make use of that rather than mix-and-match string literals and parsed items. This should make us safe with regard to versioned comments, even those spanning multiple tokens. Also no longer affected by IGNORE_SPACES. mysql-test/r/mysqlbinlog.result: LOAD DATA INFILE normalized mysql-test/suite/binlog/r/binlog_killed_simulate.result: LOAD DATA INFILE normalized mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: LOAD DATA INFILE normalized mysql-test/suite/binlog/r/binlog_stm_blackhole.result: LOAD DATA INFILE normalized mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: LOAD DATA INFILE normalized mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result: LOAD DATA INFILE normalized mysql-test/suite/rpl/r/rpl_loaddata.result: LOAD DATA INFILE normalized mysql-test/suite/rpl/r/rpl_loaddata_fatal.result: LOAD DATA INFILE normalized; offsets adjusted to reflect that mysql-test/suite/rpl/r/rpl_loaddata_map.result: LOAD DATA INFILE normalized mysql-test/suite/rpl/r/rpl_loaddatalocal.result: test for #43746 - trying to break LOAD DATA part of parser mysql-test/suite/rpl/r/rpl_stm_log.result: LOAD DATA INFILE normalized mysql-test/suite/rpl/t/rpl_loaddatalocal.test: try to break the LOAD DATA part of the parser (test for #43746) mysql-test/t/mysqlbinlog.test: LOAD DATA INFILE normalized; adjust offsets to reflect that sql/log_event.cc: clean up Load_log_event::print_query and friends so they don't print excess spaces. add support for printing charset names to print_query. sql/log_event.h: We already have three places where we synthesize LOAD DATA queries. Better use one of those! sql/sql_lex.h: When binlogging LOAD DATA statements, we make up the statement to be logged (from the parse-info, rather than substrings of the original query) now. Consequently, we no longer need (string-) pointers into the original query. sql/sql_load.cc: Completely rewrote write_execute_load_query_log_event() to synthesize the LOAD DATA statement wholesale, rather than piece it together from synthesized bits and literal excerpts from the original query. This will not only give us a nice, normalized statement (all uppercase, no excess spaces, etc.), it will also handle comments, including versioned comments right, which is certainly more than we can say about the previous incarnation. sql/sql_yacc.yy: We're no longer assembling LOAD DATA statements from bodyparts of the original query, so some bookkeeping in the parser can go.
-
Magnus Blåudd authored
-
Magnus Blåudd authored
-
Martin Hansson authored
Bug#35996: SELECT + SHOW VIEW should be enough to display view definition During SHOW CREATE VIEW there is no reason to 'anonymize' errors that name objects that a user does not have access to. Moreover it was inconsistently implemented. For example base tables being referenced from a view appear to be ok, but not views. The manual on the other hand is clear: If a user has the privileges SELECT and SHOW VIEW, the view definition is available to that user, period. The fix changes the behavior to support the manual. mysql-test/r/information_schema_db.result: Bug#35996: Changed warnings. mysql-test/r/view_grant.result: Bug#35996: Changed warnings, test result. mysql-test/t/information_schema_db.test: Bug#35996: Changed test case to reflect new behavior. mysql-test/t/view_grant.test: Bug#35996: Test case. sql/sql_acl.cc: Bug#35996: Code no longer necessary, we may as well exempt SHOW CREATE VIEW from this check. sql/sql_show.cc: Bug#35996: The fix: An Internal_error_handler that hides most errors raised by access checking as they are not relevant to SHOW CREATE VIEW. sql/table.cc: Bug#35996: Restricting this hack to act only when there is no Internal_error_handler.
-
Martin Hansson authored
Bug#46958: Assertion in Diagnostics_area::set_ok_status, trigger, merge table The problem with break statements is that they have very local effects. Hence a break statement within the inner loop of a nested-loops join caused execution to proceed to the next table even though a serious error occurred. The problem was fixed by breaking out the inner loop into its own method. The change empowers all errors to terminate the execution. The errors that will now halt multi-DELETE execution altogether are - triggers returning errors - handler errors - server being killed mysql-test/r/delete.result: Bug#46958: Test result. mysql-test/t/delete.test: Bug#46958: Test case. sql/sql_class.h: Bug#46958: New method declaration. sql/sql_delete.cc: Bug#46958: New method implementation.
-
unknown authored
All statements executed by mysql_upgrade are binlogged and then are replicated to slave. This will result in some errors. The report of this bug has demonstrated some examples. Master and slave should be upgraded separately. All statements executed by mysql_upgrade will not be binlogged. --write-binlog and --skip-write-binlog options are added into mysql_upgrade. These options control whether sql statements are binlogged or not.
-
unknown authored
In RBR, 'DROP TEMPORARY TABLE IF EXISTS...' statement is binlogged when the table does not exist. In fact, 'DROP TEMPORARY TABLE ...' statement should never be binlogged in RBR no matter if the table exists or not. This patch addresses this by checking whether we are dropping a temporary table or not, when building the custom drop statement.
-
- 27 Sep, 2009 3 commits
-
-
Luis Soares authored
HA_ERR_WRONG_INDEX In RBR, disabling keys on slave table will break replication when updating or deleting a record. When the slave thread tries to find the row, by searching in the storage engine, it checks whether the table has a key or not. If it has one, then the slave thread uses it to search the record. Nonetheless, the slave only checks whether the key exists or not, it does not verify if it is active. Should the key be disabled (eg, DBA has issued an ALTER TABLE ... DISABLE KEYS) then it will result in error: HA_ERR_WRONG_INDEX. This patch addresses this issue by making the slave thread also check whether the key is active or not before actually using it.
-
unknown authored
The failure is not reproduced on 5.1, so enable the 'rpl_cross_version' test. mysql-test/suite/rpl/t/disabled.def: Got rid of the line for enabling 'rpl_cross_version' test.
-
unknown authored
Network error happened here, but it can be caused by CR_CONNECTION_ERROR, CR_CONN_HOST_ERROR, CR_SERVER_GONE_ERROR, CR_SERVER_LOST, ER_CON_COUNT_ERROR, and ER_SERVER_SHUTDOWN. We just check CR_SERVER_LOST here, so the test fails. To fix the problem, check all errors that can be cause by the master shutdown. mysql-test/extra/rpl_tests/rpl_get_master_version_and_clock.test: Added a 'if' sentence to check all errors that can be cause by the master shutdown. mysql-test/suite/rpl/r/rpl_get_master_version_and_clock.result: Test result is updated duo to the patch of bug#46931
-
- 25 Sep, 2009 3 commits
-
-
Omer BarNir authored
from test-extra tree. Changes include improvements to error handling and are based on WL#4685
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-