- 16 Feb, 2012 15 commits
-
-
unknown authored
The problem was introduced in 5.5.20 by Bug 13116225. It tried to protect against downgrading from a version 5.6.4 database that was created with a page size other than 16k. Version 5.6.4 supports page sizes 4k and 8k and stamps that page size into the header page of each tablespace file. Version 5.5.20 attempts to read that page size in the file header. But it turns out that only the first system tablespace file has a reliable flags field in the header. So only ibdata1 can be or needs to be tested for another page size. Extra system tablespace files like ibdata2, ibdata3, etc do not and should not be tested since the flags field is unreliable.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
error LNK2001: unresolved external symbol _debug_sync_C_callback_ptr
-
Kent Boortz authored
-
Kent Boortz authored
-
Kent Boortz authored
-
MySQL Build Team authored
-
Kent Boortz authored
-
MySQL Build Team authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
OF WIDE RECORDS row_ins_index_entry_low(), row_upd_clust_rec(): Make a redo log checkpoint if a DEBUG flag is set. Add DEBUG_SYNC around btr_store_big_rec_extern_fields(). rb:946 approved by Jimmy Yang
-
Marko Mäkelä authored
-
Kent Boortz authored
-
Kent Boortz authored
-
MySQL Build Team authored
-
- 15 Feb, 2012 6 commits
-
-
Kent Boortz authored
-
MySQL Build Team authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Before killing the server, tell mysql-test-run that it is to be expected. Discussed with Bjorn Munch on IM.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 13 Feb, 2012 2 commits
-
-
Rohit Kalhans authored
-
Rohit Kalhans authored
Fixed a typo in the comment. Fixing test cases which were previouslyno throwing due disable warnings macro. sql/sql_base.cc: Change in indentation and fixing a typo in the comment.
-
- 10 Feb, 2012 4 commits
-
-
Sunny Bains authored
-
Sunny Bains authored
During FIC error handling the trx->error_state was not being set to DB_SUCCESS after failure, before attempting the next DDL SQL operation. This reset to DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere. The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit. rb://935 Approved by Jimmy Yang.
-
Sunny Bains authored
-
Sunny Bains authored
During FIC error handling the trx->error_state was not being set to DB_SUCCESS after failure, before attempting the next DDL SQL operation. This reset to DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere. The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit. rb://935 Approved by Jimmy Yang.
-
- 09 Feb, 2012 2 commits
-
-
Rohit Kalhans authored
-
Rohit Kalhans authored
Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrieved from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table based on the rows selected from another table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe. sql/share/errmsg-utf8.txt: Added new warning messages. sql/sql_base.cc: -Created function to check statements that write to tables with auto_increment column and has select. -Marked all the statements that write to a table with auto_increment column based on rows fetched from other table(s) as unsafe. sql/sql_table.cc: mark CREATE TABLE[with auto_increment column] as unsafe.
-
- 08 Feb, 2012 1 commit
-
-
Rohit Kalhans authored
-
- 07 Feb, 2012 1 commit
-
-
Rohit Kalhans authored
Problem: Statements that write to tables with auto_increment columns based on the selection from another table, may lead to master and slave going out of sync, as the order in which the rows are retrived from the table may differ on master and slave. Solution: We mark writing to a table with auto_increment table as unsafe. This will cause the execution of such statements to throw a warning and forces the statement to be logged in ROW if the logging format is mixed. Changes: 1. All the statements that writes to a table with auto_increment column(s) based on the rows fetched from another table, will now be unsafe. 2. CREATE TABLE with SELECT will now be unsafe. sql/share/errmsg-utf8.txt: Added new Warning messages sql/sql_base.cc: created a new function that checks for select + write on a autoinc table made all such statements to be unsafe. sql/sql_parse.cc: made create autoincremnet tabble + select unsafe
-
- 06 Feb, 2012 2 commits
-
-
Vasil Dimov authored
The actual Bug#11754376 does not exist in MySQL 5.5 because at startup we drop entries for temporary tables from InnoDB dictionary cache (only if ROW_FORMAT is not REDUNDANT). But nevertheless the bug in normalize_table_name_low() is present so we fix it.
-
Vasil Dimov authored
GRACEFUL SHUTDOWN During startup mysql picks up .frm files from the tmpdir directory and tries to drop those tables in the storage engine. The problem is that when tmpdir ends in / then ha_innobase::delete_table() is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it to "/#sql123" and calls row_drop_table_for_mysql() which of course fails to delete the table entry from the InnoDB dictionary cache. ha_innobase::delete_table() returns an error but nevertheless mysql wipes away the .frm file and the entry in the InnoDB dictionary cache remains orphaned with no easy way to remove it. The "no easy" way to remove it is to create a similar temporary table again, copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file after restart and will try to issue drop table for "/var/tmp/#sql123" (notice do double slash), ha_innobase::delete_table() will normalize it to "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the table entry from the dictionary cache. The solution is to fix normalize_table_name_low() to normalize things like "/var/tmp//table" correctly to "tmp/table". This patch also adds a test function which invokes normalize_table_name_low() with various inputs to make sure it works correctly and a mtr test that calls this test function. Reviewed by: Marko (http://bur03.no.oracle.com/rb/r/929/)
-
- 05 Feb, 2012 1 commit
-
-
Ashish Agarwal authored
-
- 03 Feb, 2012 4 commits
-
-
Nuno Carvalho authored
rpl_heartbeat_basic test fails sporadically on pushbuild because did not received all heartbeats from slave in circular replication. Removed from experimental collection.
-
Ashish Agarwal authored
-
Ashish Agarwal authored
CORRUPTED WHEN RUN CONCURRENTLY WITH ISSUE: Table corruption due to concurrent queries. Different threads running check, repair query along with insert. Locks not properly acquired in repair query. Rows are inserted inbetween repair query. SOLUTION: Mutex lock is acquired before the repair call. Concurrent queries wont effect the call to repair.
-
Ashish Agarwal authored
-
- 02 Feb, 2012 2 commits
-
-
Ashish Agarwal authored
ON 64 BIT MACHINES PROBLEM: When sorting index during repair of myisam tables, due to improper casting of buffer size variables value of myisam_ sort_buffer_size is not set greater than 4GB. SOLUTION: Proper casting of buffer size variable. myisam_buffer_size changed to unsigned long long to handle size > 4GB on linux as well as windows.
-
Alexander Barkov authored
-