mariadb

Tree: 59c79cc5d0

Author	SHA1	Message	Date
Joerg Bruehe	59c79cc5d0	Bug#65745: UPDATE ON INNODB TABLE ENTERS RECURSION Introduction of cost based decision on filesort vs index for UPDATE statements changed detection of the fact that the index used to scan the table is being updated. The new design missed the case of index merge when there is no single index to check. That was worked until a recent change in InnoDB after which it went into infinite recursion if update of the used index wasn't properly detected. The fix consists of 'used key being updated' detection code from 5.1. Patch done by Evgeny Potemkin <evgeny.potemkin@oracle.com> and transferred into the 5.5.25a release build by Joerg Bruehe. This changeset is the difference between MySQL 5.5.25 and 5.5.25a. VERSION: Version number change. sql/sql_update.cc: Bug#65745: UPDATE ON INNODB TABLE ENTERS RECURSION The check for used key being updated is extended to cover the case when index merge is used.	14 years ago
Annamalai Gurusami	326b40c9c8	Merging from mysql-5.1 to mysql-5.5.	14 years ago
Annamalai Gurusami	391ea219c2	Bug #14007649 65111: INNODB SOMETIMES FAILS TO UPDATE ROWS INSERTED BY A CONCURRENT TRANSACTIO The member function QUICK_RANGE_SELECT::init_ror_merged_scan() performs a table handler clone. Innodb does not provide a clone operation. The ha_innobase::clone() is not there. The handler::clone() does not take care of the ha_innobase->prebuilt->select_lock_type. Because of this what happens is that for one index we do a locking read, and for the other index we were doing a non-locking (consistent) read. The patch introduces ha_innobase::clone() member function. It is implemented similar to ha_myisam::clone(). It calls the base class handler::clone() and then does any additional operation required. I am setting the ha_innobase->prebuilt->select_lock_type correctly. rb://1060 approved by Marko	14 years ago
Georgi Kodinov	63dac66356	merge	14 years ago
Sunanda Menon	074ce71e90	Merge from mysql-5.1.63-release	14 years ago
Joerg Bruehe	5be07ceadd	Merge 5.5.24 back into main 5.5. This is a weave merge, but without any conflicts. In 14 source files, the copyright year needed to be updated to 2012.	14 years ago
Venkata Sidagam	1d47bbe3bf	Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY CAUSES RESTORE PROBLEM Merging the fix from mysql-5.1 to mysql-5.5 mysql-test/t/mysqldump.test: There is a difference in the testcase which is added as part of this fix, when compared with mysql-5.1. In mysql-5.5 and mysql-5.6, "DROP mysql database" fails by enabling logging, hence removed those lines.	14 years ago
Venkata Sidagam	e7364ec29c	Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY CAUSES RESTORE PROBLEM Problem Statement: ------------------ mysqldump is not having the dump stmts for general_log and slow_log tables. That is because of the fix for Bug#26121. Hence, after dropping the mysql database, and applying the dump by enabling the logging, "'general_log' table not found" errors are logged into the server log file. Analysis: --------- As part of the fix for Bug#26121, we skipped the dumping of tables for general_log and slow_log, because the data dump of those tables are taking LOCKS, which is not allowed for log tables. Fix: ---- We came up with an approach that instead of taking both meta data and data dump information for those tables, take only the meta data dump which doesn't need LOCKS. As part of fixing the issue we came up with below algorithm. Design before fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. Design with the fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Explicitly call the 'show create table' for general_log and slow_log 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. While taking the meta data dump for general_log and slow_log the "CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". This is because we skipped "DROP TABLE" for those tables, "DROP TABLE" fails for these tables if logging is enabled. Customer is applying the dump by enabling logging so, if the dump has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" stmts for those tables. After the fix we could observe "Table 'mysql.general_log' doesn't exist" errors initially that is because in the customer scenario they are dropping the mysql database by enabling the logging, Hence, those errors are expected. Once we apply the dump which is taken before the "drop database mysql", the errors will not be there. client/mysqldump.c: In get_table_structure() added code to skip the DROP TABLE stmts for general_log and slow_log tables, because when logging is enabled those stmts will fail. And replaced CREATE TABLE with CREATE IF NOT EXISTS for those tables, just to make sure CREATE stmt for those tables doesn't fail since we removed DROP stmts for those tables. In dump_all_tables_in_db() added code to call get_table_structure() for general_log and slow_log tables. mysql-test/r/mysqldump.result: Added a test as part of fix for Bug #11754178 mysql-test/t/mysqldump.test: Added a test as part of fix for Bug #11754178	14 years ago
Venkata Sidagam	daafaa0f86	Bug #11754178 45740: MYSQLDUMP DOESN'T DUMP GENERAL_LOG AND SLOW_QUERY CAUSES RESTORE PROBLEM Problem Statement: ------------------ mysqldump is not having the dump stmts for general_log and slow_log tables. That is because of the fix for Bug#26121. Hence, after dropping the mysql database, and applying the dump by enabling the logging, "'general_log' table not found" errors are logged into the server log file. Analysis: --------- As part of the fix for Bug#26121, we skipped the dumping of tables for general_log and slow_log, because the data dump of those tables are taking LOCKS, which is not allowed for log tables. Fix: ---- We came up with an approach that instead of taking both meta data and data dump information for those tables, take only the meta data dump which doesn't need LOCKS. As part of fixing the issue we came up with below algorithm. Design before fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. Design with the fix: 1) mysql database is having tables like db, event,... general_log, ... slow_log... 2) Skip general_log and slow_log while preparing the tables list 3) Explicitly call the 'show create table' for general_log and slow_log 3) Take the TL_READ lock on tables which are present in the table list and do 'show create table'. 4) Release the lock. While taking the meta data dump for general_log and slow_log the "CREATE TABLE" is replaced with "CREATE TABLE IF NOT EXISTS". This is because we skipped "DROP TABLE" for those tables, "DROP TABLE" fails for these tables if logging is enabled. Customer is applying the dump by enabling logging so, if the dump has "DROP TABLE" it will fail. Hence, removed the "DROP TABLE" stmts for those tables. After the fix we could observe "Table 'mysql.general_log' doesn't exist" errors initially that is because in the customer scenario they are dropping the mysql database by enabling the logging, Hence, those errors are expected. Once we apply the dump which is taken before the "drop database mysql", the errors will not be there. client/mysqldump.c: In get_table_structure() added code to skip the DROP TABLE stmts for general_log and slow_log tables, because when logging is enabled those stmts will fail. And replaced CREATE TABLE with CREATE IF NOT EXISTS for those tables, just to make sure CREATE stmt for those tables doesn't fail since we removed DROP stmts for those tables. In dump_all_tables_in_db() added code to call get_table_structure() for general_log and slow_log tables. mysql-test/r/mysqldump.result: Added a test as part of fix for Bug #11754178 mysql-test/t/mysqldump.test: Added a test as part of fix for Bug #11754178	14 years ago
Annamalai Gurusami	b757c13078	In perl, to break out of a foreach loop we need to use the keyword "last" and not "break". Fixing the failing test case.	14 years ago
Alexander Nozdrin	95205bbaff	Third attempt to do a follow-up for Bug#12762885 - 61713: MYSQL WILL NOT BIND TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED. Previous commit comments were wrong. The default value has always been NULL. The original patch for Bug#12762885 just makes it visible in the logs. This patch uses "0.0.0.0" string if bind-address is not set.	14 years ago
Alexander Nozdrin	476762bd7b	Revert two follow-ups for Bug#12762885: - alexander.nozdrin@oracle.com-20120427151428-7llk1mlwx8xmbx0t - alexander.nozdrin@oracle.com-20120427144227-kltwiuu8snds4j3l.	14 years ago
Alexander Nozdrin	25cdec81e0	Proper follow-up for Bug#12762885 - 61713: MYSQL WILL NOT BIND TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED. The original patch removed default value of the bind-address option. So, the default value became NULL. By coincedence NULL resolves to 0.0.0.0 and ::, and since the server chooses first IPv4-address, 0.0.0.0 is choosen. So, there was no change in the behaviour. This patch restores default value of the bind-address option to "0.0.0.0".	14 years ago
Alexander Nozdrin	6fa011056a	Follow-up for Bug#12762885 - 61713: MYSQL WILL NOT BIND TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED. The original patch removed default value of the bind-address option. So, the default value became NULL. By coincedence NULL resolves to 0.0.0.0 and ::, and since the server chooses first IPv4-address, 0.0.0.0 is choosen. So, there was no change in the behaviour. This patch restores default value of the bind-address option to "0.0.0.0".	14 years ago
Yasufumi Kinoshita	96b62513f6	Bug#11758510 (#50723 ): INNODB CHECK TABLE FATAL SEMAPHORE WAIT TIMEOUT POSSIBLY TOO SHORT FOR BI Fixed not to check timeout during the check table.	14 years ago
Yasufumi Kinoshita	08e7444e54	Bug#11758510 (#50723 ): INNODB CHECK TABLE FATAL SEMAPHORE WAIT TIMEOUT POSSIBLY TOO SHORT FOR BI Fixed not to check timeout during the check table.	14 years ago
irana	02522904bc	merge from 5.1	14 years ago
irana	1a2cf649dc	InnoDB: Adjust error message when a dropped tablespace is accessed.	14 years ago
Manish Kumar	3f98e95354	BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2 Problem - The failure on PB2 is possbily due to the port number being still in use even after the server restarts which is not reflected in the server restart. Fix - The problem is fixed by starting the servers forcefully using the option file and also the parameters for the server restart is passed correctly. mysql-test/suite/rpl/t/rpl_report_port-master.opt: Option file for the master.	14 years ago
Inaam Rana	08ead005b1	Bug#13990648: 65061: LRU FLUSH RATE CALCULATION IS BASED ON INVALID VALUES rb://1043 approved by: Sunny Bains Two internal counters were incremented twice for a single operations. The counters are: srv_buf_pool_flushed buf_lru_flush_page_count	14 years ago
Georgi Kodinov	b872ce0312	Fixed a cmake compile problem because of the 2.8.8 fix.	14 years ago
Georgi Kodinov	e881e03e01	Bug #59148 - made tests experimental Fixed a cmake 2.8.8 compilation problem.	14 years ago
Kent Boortz	18e2bee9d1	Merge	14 years ago
Kent Boortz	678f221cb9	Allow Windows absolute paths in N:\ formatfor the --vardir option	14 years ago
Inaam Rana	2415d955c8	Bug#12677594 - 61575: INNODB: WARNING: IO_SETUP() FAILED WITH EAGAIN. rb://1033 approved by: Marko Makela Check return value from os_aio_init() and refuse to start if it fails.	14 years ago
Andrei Elkin	d8ac252f0e	merge from 5.1 (null)	14 years ago
Andrei Elkin	f189ccf530	merge from 5.1 repo	14 years ago
Andrei Elkin	fd9e7e2737	null merge from 5.1.	14 years ago
Andrei Elkin	bd0c38064f	BUG#11754117 rpl_auto_increment_bug45679.test is refined due to not fixed in 5.1 Bug11749859-39934.	14 years ago
Andrei Elkin	da7436a2a8	merge bug11754117-45670 fixes from 5.1: fixing comments in sql_lex.h.	14 years ago
Andrei Elkin	6d74c922af	merge bug11754117-45670 fixes from 5.1: fixing result files.	14 years ago
Andrei Elkin	14de6de946	merge bug11754117-45670 fixes from 5.1.	14 years ago
Mayank Prasad	dcb5071b19	BUG#12427262 : 60961: SHOW TABLES VERY SLOW WHEN NOT IN SYSTEM DISK CACHE Details: - test case bug12427262.test was failing on windows because on windows '/' was not recognized. And this was used in LIKE clause of the query being run in this test case. Fix: - Windows needs '\\\\' for path seperater in mysql. I was not sure how to keep a single query with two different syntax based on platform. So modifying query to make sure it runs correctly on both platform.	14 years ago
Nuno Carvalho	d3968407e6	BUG#13979418: SHOW BINLOG EVENTS MAY CRASH THE SERVER Merge from 5.1 into 5.5. Conflicts: * sql/log.h * sql/sql_repl.cc	14 years ago
Nuno Carvalho	cdaae1692b	BUG#13979418: SHOW BINLOG EVENTS MAY CRASH THE SERVER The function mysql_show_binlog_events has a local stack variable 'LOG_INFO linfo;', which is assigned to thd->current_linfo, however this variable goes out of scope and is destroyed before clean thd->current_linfo. The problem is solved by moving 'LOG_INFO linfo;' to function scope.	14 years ago
Andrei Elkin	49e484c8cd	BUG#11754117 incorrect logging of INSERT into auto-increment BUG#11761686 insert_id event is not filtered. Two issues are covered. INSERT into autoincrement field which is not the first part in the composed primary key is unsafe by autoincrement logging design. The case is specific to MyISAM engine because Innodb does not allow such table definition. However no warnings and row-format logging in the MIXED mode was done, and that is fixed. Int-, Rand-, User-var log-events were not filtered along with their parent query that made possible them to screw up execution context of the following query. Fixed with deferring their execution until the parent query. ****** Bug#11754117 Post review fixes. mysql-test/suite/rpl/r/rpl_auto_increment_bug45679.result: a new result file is added. mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.result: results updated. mysql-test/suite/rpl/t/rpl_auto_increment_bug45679.test: regression test for BUG#11754117-45670 is added. mysql-test/suite/rpl/t/rpl_filter_tables_not_exist.test: regression test for filtering issue of BUG#11754117 - 45670 is added. sql/log_event.cc: Logics are added for deferring and executing events associated with the Query event. sql/log_event.h: Interface to deferred events batch execution is added. sql/rpl_rli.cc: initialization for new RLI members is added. sql/rpl_rli.h: New members to RLI are added to facilitate deferred events gathering and execution control; two general character RLI cleanup methods are constructed. sql/rpl_utility.cc: Deferred_log_events methods are difined. sql/rpl_utility.h: A new class Deferred_log_events is defined to implement IRU events gathering, execution and cleanup. sql/slave.cc: Necessary changes to initialize `rli->deferred_events' and prevent deferred event deletion in the main read-exec branch. sql/sql_base.cc: A new safe-check function for multi-part pk with auto-increment is defined and deployed in lock_tables(). sql/sql_class.cc: Initialization for a new member and replication cleanups are added to THD class. sql/sql_class.h: THD class receives a new member to hold a specific execution context for slave applier. sql/sql_parse.cc: Execution of the deferred event in started prior to its parent query.	14 years ago
Mayank Prasad	a7d47adf23	BUG#12427262 : 60961: SHOW TABLES VERY SLOW WHEN NOT IN SYSTEM DISK CACHE Details: - Merge : 5.1 -> 5.5 - Addded a new test case which was not added in 5.1 because PS was not there in 5.1.	14 years ago
Mayank Prasad	bf4161adae	BUG#12427262 : 60961: SHOW TABLES VERY SLOW WHEN NOT IN SYSTEM DISK CACHE Reason: This is a regression happened because of changes done in code refactoring in 5.1 from 5.0. Issue: While doing "Show tables" lex->verbose was being checked to avoid opening FRM files to get table type. In case of "Show full table", lex->verbose is true to indicate table type is required. In 5.0, this check was present which got missing in >=5.5. Fix: Added the required check to avoid opening FRM files unnecessarily in case of "Show tables".	14 years ago
Tor Didriksen	8330371334	NULL merge 5.1 => 5.5	14 years ago
Tor Didriksen	892106db92	new header file must be listed in Makefile.am	14 years ago
Tor Didriksen	0bd0de71fa	NULL merge 5.1 => 5.5	14 years ago
Tor Didriksen	11b2cf4f03	Backport 5.5=>5.1 Patch for Bug#13805127: Stored program cache produces wrong result in same THD.	14 years ago
Annamalai Gurusami	b73da023bf	Bug #12902967 Creating self referencing fk on same index unhandled, confusing error. Updated the test script to work properly on windows platform.	14 years ago
Nuno Carvalho	5e126b505a	WL#6236: Allow SHOW MASTER LOGS and SHOW BINARY LOGS with REPLICATION CLIENT Merge from 5.1 into 5.5.	14 years ago
Nuno Carvalho	448c3d6275	WL#6236: Allow SHOW MASTER LOGS and SHOW BINARY LOGS with REPLICATION CLIENT Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER privilege. Monitoring tools (such as MEM) often want to check this output - for instance MEM generates the SUM of the sizes of the logs reported here, and puts that in the Replication overview within the MEM Dashboard. However, because of the SUPER requirement, these tools often have an account that holds open the connection whilst monitoring, and can lock out administrators when the server gets overloaded and reaches max_connections - there is already another SUPER privileged account connected, the "monitor". As SHOW MASTER STATUS, and all other replication related statements, return with either REPLICATION CLIENT or SUPER privileges, this worklog is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this as well, and allow both of these commands with either SUPER or REPLICATION CLIENT. This allows monitoring tools to not require a SUPER privilege any more, so is safer in overloaded situations, as well as being more secure, as lighter privileges can be given to users of such tools or scripts.	14 years ago
Chaithra Gopalareddy	eff1ec5fcc	Merge from 5.1 to 5.5 mysql-test/r/select.result: Added test result for Bug#12713907 mysql-test/t/select.test: Added test case for Bug#12713907 sql/sql_select.cc: Remove the call to set_keyread as we do it from access functions 'join_read_first' and 'join_read_last'	14 years ago
Chaithra Gopalareddy	25f82f8a26	Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER ORDER BY COUNT(*) LIMIT. PROBLEM: With respect to problem in the bug description, we exhibit different behaviors for the two tables presented, because innodb statistics (rec_per_key in this case) are updated for the first table and not so for the second one. As a result the query plan gets changed in test_if_skip_sort_order to use 'index' scan. Hence the difference in the explain output. (NOTE: We can reproduce the problem with first table by reducing the number of tuples and changing the table structure) The varied output w.r.t the query on the second table is because of the result in the query plan change. When a query plan is changed to use 'index' scan, after the call to test_if_skip_sort_order, we set keyread to TRUE immedietly. If for some reason we drop this index scan for a filesort later on, we fetch only the keys not the entire tuple. As a result we would see junk values in the result set. Following is the code flow: Call test_if_skip_sort_order -Choose an index to give sorted output -If this is a covering index, set_keyread to TRUE -Set the scan to INDEX scan Call test_if_skip_sort_order second time -Index is not chosen (note that we do not pass the actual limit value second time. Hence we do not choose index scan second time which in itself is a bug fixed in 5.6 with WL#5558) -goto filesort Call filesort -Create quick range on a different index -Since keyread is set to TRUE, we fetch only the columns of the index -results in the required columns are not fetched FIX: Remove the call to set_keyread(TRUE) from test_if_skip_sort_order. The access function which is 'join_read_first' or 'join_read_last' calls set_keyread anyways. mysql-test/r/func_group_innodb.result: Added test result for Bug#12713907 mysql-test/t/func_group_innodb.test: Added test case for Bug#12713907 sql/sql_select.cc: Remove the call to set_keyread as we do it from access functions 'join_read_first' and 'join_read_last'	14 years ago
Annamalai Gurusami	75ff20a2b4	Bug #12902967 Creating self referencing fk on same index unhandled, confusing error. I have added the not_embedded.inc in the test file.	14 years ago
Annamalai Gurusami	fe04006941	Bug #12902967 CREATING SELF REFERENCING FK ON SAME INDEX UNHANDLED, CONFUSING ERROR The main confusion with the error message is that "it implies that your data dictionary may now be out of sync". This patch will remove the unwanted and the misleading error message by not doing an unnecessary operation in the error handling code. rb://980 approved by: Dmitry Lenev	14 years ago
Georgi Kodinov	7587398661	empty merge of a version bump in mysql-5.1	14 years ago

1 2 3 4 5 ...

70499 Commits (59c79cc5d0f1dab2db65f3d55ffe6a5a777b85c1) All Branches Search

70499 Commits (59c79cc5d0f1dab2db65f3d55ffe6a5a777b85c1)

All Branches