mariadb

Tree: e231e7f8eb

Author	SHA1	Message	Date
Georgi Kodinov	2146ef6f3f	merge	14 years ago
Sunanda Menon	d37a28c9b0	Merge from mysql-5.1.63-release	14 years ago
Joerg Bruehe	ad1e123f47	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	066dc9a281	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	14 years ago
Venkata Sidagam	14aa2c020e	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.	14 years ago
Venkata Sidagam	41cdad9868	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.	14 years ago
Annamalai Gurusami	f619c8ce83	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	bcc3d5ce25	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	5f4c6942bf	Revert two follow-ups for Bug#12762885: - alexander.nozdrin@oracle.com-20120427151428-7llk1mlwx8xmbx0t - alexander.nozdrin@oracle.com-20120427144227-kltwiuu8snds4j3l.	14 years ago
Alexander Nozdrin	3885dc55dd	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	cb4490919b	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	6e1eb5bd39	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	d90207321b	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	0e6250743c	merge from 5.1	14 years ago
irana	b9632549a9	InnoDB: Adjust error message when a dropped tablespace is accessed.	14 years ago
Manish Kumar	4b917744a2	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.	14 years ago
Inaam Rana	03b4ec4aa2	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	943a778e6a	Fixed a cmake compile problem because of the 2.8.8 fix.	14 years ago
Georgi Kodinov	672395db74	Bug #59148 - made tests experimental Fixed a cmake 2.8.8 compilation problem.	14 years ago
Kent Boortz	2b877ca2bb	Merge	14 years ago
Kent Boortz	9927a07bc1	Allow Windows absolute paths in N:\ formatfor the --vardir option	14 years ago
Inaam Rana	57202cbfc5	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	611d961079	merge from 5.1 (null)	14 years ago
Andrei Elkin	a891de4221	merge from 5.1 repo	14 years ago
Andrei Elkin	e0e6203451	null merge from 5.1.	14 years ago
Andrei Elkin	d5925c2044	BUG#11754117 rpl_auto_increment_bug45679.test is refined due to not fixed in 5.1 Bug11749859-39934.	14 years ago
Andrei Elkin	8f737d31fd	merge bug11754117-45670 fixes from 5.1: fixing comments in sql_lex.h.	14 years ago
Andrei Elkin	ec2caa37ba	merge bug11754117-45670 fixes from 5.1: fixing result files.	14 years ago
Andrei Elkin	bf66e3ab63	merge bug11754117-45670 fixes from 5.1.	14 years ago
Mayank Prasad	e748999eb5	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	8ac39aa8e0	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	ca33df2094	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	f3509d1d67	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.	14 years ago
Mayank Prasad	2786a6e232	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	5203d9bb98	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	cf162c762e	NULL merge 5.1 => 5.5	14 years ago
Tor Didriksen	adb352ca3e	new header file must be listed in Makefile.am	14 years ago
Tor Didriksen	18acee0ff2	NULL merge 5.1 => 5.5	14 years ago
Tor Didriksen	d612986b36	Backport 5.5=>5.1 Patch for Bug#13805127: Stored program cache produces wrong result in same THD.	14 years ago
Annamalai Gurusami	46c51c40e1	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	0eea06c5d0	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	a9a7e6ea24	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	2479f3cb7b	Merge from 5.1 to 5.5	14 years ago
Chaithra Gopalareddy	81058259c7	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.	14 years ago
Annamalai Gurusami	30b2e00584	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	6fc42540f8	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	3190511215	empty merge of a version bump in mysql-5.1	14 years ago
Georgi Kodinov	91696e2244	Raise version number after cloning 5.1.63	14 years ago
Joerg Bruehe	5bfa33da6e	Raise version number after cloning for the 5.5.24 build.	14 years ago
Tor Didriksen	582b728347	Bug#13871079 RQG_MYISAM_DML_ALTER_VALGRIND FAILS ON VALGRIND PN PB2 The class Copy_field contains a String tmp, which may allocate memory on the heap. That means that all instances of Copy_field must be properly destroyed. Alas they are not. Solution: don't use Copy_field::tmp for copying from_field => tmp => to_field in do_field_string()	14 years ago

... 2 3 4 5 6 ...

70646 Commits (e231e7f8eb85ebe8b0170060d3bcf66e44fa8ed8) All Branches Search

70646 Commits (e231e7f8eb85ebe8b0170060d3bcf66e44fa8ed8)

All Branches