mariadb

Commit Graph

Author	SHA1	Message	Date
Andrei Elkin	e3c8fb4a1c	Bug#14275000 Fixes for BUG11761686 left a flaw that managed to slip away from testing. Only effective filtering branch was actually tested with a regression test added to rpl_filter_tables_not_exist. The reason of the failure is destuction of too early mem-root-allocated memory at the end of the deferred User-var's do_apply_event(). Fixed with bypassing free_root() in the deferred execution branch. Deallocation of created in do_apply_event() items is done by the base code through THD::cleanup_after_query() -> free_items() that the parent Query can't miss. sql/log_event.cc: Do not call free_root() in case the deferred User-var event. Necessary methods to the User-var class are added, do_apply_event() refined. sql/log_event.h: Necessary methods to avoid destoying mem-root-based memory at User-var applying are defined.	14 years ago
Rohit Kalhans	91c8e79fcd	BUG#11762667:MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT This is a followup patch for the bug enabling the test i_binlog.binlog_mysqlbinlog_file_write.test this was disabled in mysql trunk and mysql 5.5 as in the release build mysqlbinlog was not debug compiled whereas the mysqld was. Since have_debug.inc script checks only for mysqld to be debug compiled, the test was not being skipped on release builds. We resolve this problem by creating a new inc file mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog to be debug compiled. if not it skips the test. mysql-test/include/mysqlbinlog_have_debug.inc: new inc file to check if mysqlbinlog is debug compiled.	14 years ago
Gleb Shchepa	521deaf36f	minor update to make MSVS happy	14 years ago
Georgi Kodinov	107c894a54	Bug #13708485 : malformed resultset packet crashes client Several fixes : * sql-common/client.c Added a validity check of the fields metadata packet sent by the server. Now libmysql will check if the length of the data sent by the server matches what's expected by the protocol before using the data. * client/mysqltest.cc Fixed the error handling code in mysqltest to avoid sending new commands when the reading the result set failed (and there are unread data in the pipe). * sql_common.h + libmysql/libmysql.c + sql-common/client.c unpack_fields() now generates a proper error when it fails. Added a new argument to this function to support the error generation. * sql/protocol.cc Added a debug trigger to cause the server to send a NULL insted of the packet expected by the client for testing purposes.	14 years ago
Jon Olav Hauglid	1ede2dd814	Bug#14238406 NEW COMPILATION WARNINGS WITH GCC 4.7 (-WERROR=NARROWING) This patch fixes various compilation warnings of the type "error: narrowing conversion of 'x' from 'datatype1' to 'datatype2'	14 years ago
Gleb Shchepa	767501fb54	Backport of the deprecation warning from WL#6219: "Deprecate and remove YEAR(2) type" Print the warning(note): YEAR(x) is deprecated and will be removed in a future release. Please use YEAR(4) instead on "CREATE TABLE ... YEAR(x)" or "ALTER TABLE MODIFY ... YEAR(x)", where x != 4	14 years ago
Norvald H. Ryeng	07a17e302c	Merge.	14 years ago
Harin Vadodaria	61e428eb84	Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST INC_HOST_ERRORS() IS CALLED. Description: Reverting patch 3755 for bug#11753779	14 years ago
Norvald H. Ryeng	cac1cd88ab	Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES Problem: Some queries with subqueries and a HAVING clause that consists only of a column not in the select or grouping lists causes the server to crash. During parsing, an Item_ref is constructed for the HAVING column. The name of the column is resolved when JOIN::prepare calls fix_fields() on its having clause. Since the column is not mentioned in the select or grouping lists, a ref pointer is not found and a new Item_field is created instead. The Item_ref is replaced by the Item_field in the tree of HAVING clauses. Since the tree consists only of this item, the pointer that is updated is JOIN::having. However, st_select_lex::having still points to the Item_ref as the root of the tree of HAVING clauses. The bug is triggered when doing filesort for create_sort_index(). When find_all_keys() calls select->cond->walk() it eventually reaches Item_subselect::walk() where it continues to walk the having clauses from lex->having. This means that it finds the Item_ref instead of the new Item_field, and Item_ref::walk() tries to dereference the ref pointer, which is still null. The crash is reproducible only in 5.5, but the problem lies latent in 5.1 and trunk as well. Fix: After calling fix_fields on the having clause in JOIN::prepare(), set select_lex::having to point to the same item as JOIN::having. This patch also fixes a bug in 5.1 and 5.5 that is triggered if the query is executed as a prepared statement. The Item_field is created in the runtime arena when the query is prepared, and the pointer to the item is saved by st_select_lex::fix_prepare_information() and brought back as a dangling pointer when the query is executed, after the runtime arena has been reclaimed. Fix: Backport fix from trunk that switches to the permanent arena before calling Item_ref::fix_fields() in JOIN::prepare(). sql/item.cc: Set context when creating Item_field. sql/sql_select.cc: Switch to permanent arena and update select_lex->having.	14 years ago
unknown	bc42eaf952	Raise version number after cloning 5.1.64	14 years ago
unknown	775293b898	BUG #13946716 : FEDERATED_PLUGIN TEST CASE FAIL ON 64BIT ARCHITECTURES	14 years ago
Harin Vadodaria	cf37a481f0	Bug#11753779: MAX_CONNECT_ERRORS WORKS ONLY WHEN 1ST INC_HOST_ERRORS() IS CALLED. Issue : Sequence of calling inc_host_errors() and reset_host_errors() required some changes in order to maintain correct connection error count. Solution : Call to reset_host_errors() is shifted to a location after which no calls to inc_host_errors() are made.	14 years ago
Manish Kumar	4a2d65cc31	BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET Problem ======== Replication breaks in the cases if the event length exceeds the size of master Dump thread's max_allowed_packet. The reason why this failure is occuring is because the event length is more than the total size of the max_allowed_packet, on addition of the max_event_header length exceeds the max_allowed_packet of the DUMP thread. This causes the Dump thread to break replication and throw an error. That can happen e.g with row-based replication in Update_rows event. Fix ==== The problem is fixed in 2 steps: 1.) The Dump thread limit to read event is increased to the upper limit i.e. Dump thread reads whatever gets logged in the binary log. 2.) On the slave side we increase the the max_allowed_packet for the slave's threads (IO/SQL) by increasing it to 1GB. This is done using the new server option (slave_max_allowed_packet) included, is used to regulate the max_allowed_packet of the slave thread (IO/SQL) by the DBA, and facilitates the sending of large packets from the master to the slave. This causes the large packets to be received by the slave and apply it successfully. sql/log_event.cc: The max_allowed_packet is not evaluated to the new option slave_max_allowed_packet after the fix. sql/log_event.h: Added the new option in the log_event.h file. sql/mysqld.cc: Added a new option to the server. sql/slave.cc: Increasing the session max_allowed_packet to a large value, i.e. not taking global(max_allowed) into consideration, for the slave's threads. sql/sql_repl.cc: The dump thread's max_allowed_packet is set to the upper limit which makes it independent and it now reads whatever gets logged in the binary log.	14 years ago
Tor Didriksen	2b085e1fba	Bug#14051002 VALGRIND: CONDITIONAL JUMP OR MOVE IN RR_CMP / MY_QSORT Patch for 5.1 and 5.5: fix typo in byte comparison in rr_cmp()	14 years ago
Annamalai Gurusami	a28a2ca798	Bug #13933132 : [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED WHEN KILLING Suppose there is a query waiting for a lock. If the user kills this query, then "Got error -1 when reading table" error message must not be logged in the server log file. Since this is a user requested interruption, no spurious error message must be logged in the server log. This patch will remove the error message from the log. approved by joh and tatjana	14 years ago
unknown	2ebd927ec0		14 years ago
unknown	70d01f5182		14 years ago
unknown	f8a6521789		14 years ago
Rohit Kalhans	96eb519eb7	Fixing the build failure on Windows debug build.	14 years ago
Rohit Kalhans	d8b2d4a069	Bug#11762667: MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT Problem: mysqlbinlog exits without any error code in case of file write error. It is because of the fact that the calls to Log_event::print() method does not return a value and the thus any error were being ignored. Resolution: We resolve this problem by checking for the IO_CACHE::error == -1 after every call to Log_event:: print() and terminating the further execution. client/mysqlbinlog.cc: - handled error conditions during event->print() calls - added check for error in end_io_cache() mysys/my_write.c: Added debug code to simulate file write error. error returned will be ENOSPC=> error no space on the disk sql/log_event.cc: Added debug code to simulate file write error, by reducing the size of io cache.	14 years ago
Inaam Rana	01748ce128	Bug #14100254 65389: MVCC IS BROKEN WITH IMPLICIT LOCK rb://1088 approved by: Marko Makela This bug was introduced in early stages of plugin. We were not checking for an implicit lock on sec index rec for trx_id that is stamped on current version of the clust_index in case where the clust_index has a previous delete marked version.	14 years ago
Annamalai Gurusami	e979417c06	Bug #12752572 61579: REPLICATION FAILURE WHILE INNODB_AUTOINC_LOCK_MODE=1 AND USING TRIGGER When an insert stmt like "insert into t values (1),(2),(3)" is executed, the autoincrement values assigned to these three rows are expected to be contiguous. In the given lock mode (innodb_autoinc_lock_mode=1), the auto inc lock will be released before the end of the statement. So to make the autoincrement contiguous for a given statement, we need to reserve the auto inc values at the beginning of the statement. Modified the fix based on review comment by Svoj.	14 years ago
Manish Kumar	1605b7f68f	BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET Problem ======== SQL statements close to the size of max_allowed_packet produce binary log events larger than max_allowed_packet. The reason why this failure is occuring is because the event length is more than the total size of the max_allowed_packet + max_event_header length. Now since the event length exceeds this size master Dump thread is unable to send the packet on to the slave. That can happen e.g with row-based replication in Update_rows event. Fix ==== The problem was fixed by increasing the max_allowed_packet for the slave's threads (IO/SQL) by increasing it to 1GB. This is done using the new server option included which is used to regulate the max_allowed_packet of the slave thread (IO/SQL). This causes the large packets to be received by the slave and apply it successfully. sql/log_event.h: Added the new option in the log_event.h file. sql/mysqld.cc: Added a new option to the server. sql/slave.cc: Increasing the session max_allowed_packet to a large value , i.e. not taking global(max_allowed) into consideration, for the slave's threads.	14 years ago
Rohit Kalhans	781137c0dd	BUG#14005409 - 64624 Problem: After the fix for Bug#12589870, a new field that stores the length of db name was added in the buffer that stores the query to be executed. Unlike for the plain user session, the replication execution did not allocate the necessary chunk in Query-event constructor. This caused an invalid read while accessing this field. Solution: We fix this problem by allocating a necessary chunk in the buffer created in the Query_log_event::Query_log_event() and store the length of database name. sql/log_event.cc: Added a new field in the buffer created in the Query_log_event's constructor and store the length of database name.	14 years ago
Gopal Shankar	21faded51e	Bug#12636001 : deadlock from thd_security_context PROBLEM: Threads end-up in deadlock due to locks acquired as described below, con1: Run Query on a table. It is important that this SELECT must back-off while trying to open the t1 and enter into wait_for_condition(). The SELECT then is blocked trying to lock mysys_var->mutex which is held by con3. The very significant fact here is that mysys_var->current_mutex will still point to LOCK_open, even if LOCK_open is no longer held by con1 at this point. con2: Try dropping table used in con1 or query some table. It will hold LOCK_open and be blocked trying to lock kernel_mutex held by con4. con3: Try killing the query run by con1. It will hold THD::LOCK_thd_data belonging to con1 while trying to lock mysys_var->current_mutex belonging to con1. But current_mutex will point to LOCK_open which is held by con2. con4: Get innodb engine status It will hold kernel_mutex, trying to lock THD::LOCK_thd_data belonging to con1 which is held by con3. So while technically only con2, con3 and con4 participate in the deadlock, con1's mysys_var->current_mutex pointing to LOCK_open is a vital component of the deadlock. CYCLE = (THD::LOCK_thd_data -> LOCK_open -> kernel_mutex -> THD::LOCK_thd_data) FIX: LOCK_thd_data has responsibility of protecting, 1) thd->query, thd->query_length 2) VIO 3) thd->mysys_var (used by KILL statement and shutdown) 4) THD during thread delete. Among above responsibilities, 1), 2)and (3,4) seems to be three independent group of responsibility. If there is different LOCK owning responsibility of (3,4), the above mentioned deadlock cycle can be avoid. This fix introduces LOCK_thd_kill to handle responsibility (3,4), which eliminates the deadlock issue. Note: The problem is not found in 5.5. Introduction MDL subsystem caused metadata locking responsibility to be moved from TDC/TC to MDL subsystem. Due to this, responsibility of LOCK_open is reduced. As the use of LOCK_open is removed in open_table() and mysql_rm_table() the above mentioned CYCLE does not form. Revision ID for changes, open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw	14 years ago
unknown	3e1758d36a		14 years ago
unknown	932376f97a		14 years ago
Annamalai Gurusami	ce9e6b5a9a	Bug #13943231 : ALTER TABLE AFTER DISCARD MAY CRASH THE SERVER The following scenario crashes our mysql server: 1. set global innodb_file_per_table=1; 2. create table t1(c1 int) engine=innodb; 3. alter table t1 discard tablespace; 4. alter table t1 add unique index(c1); Step 4 crashes the server. This patch introduces a check on discarded tablespace to avoid the crash. rb://1041 approved by Marko Makela	14 years ago
Venkata Sidagam	6b05e434bf	Bug #13955256 : KEYCACHE CRASHES, CORRUPTIONS/HANGS WITH, FULLTEXT INDEX AND CONCURRENT DML. Problem Statement: ------------------ 1) Create a table with FT index. 2) Enable concurrent inserts. 3) In multiple threads do below operations repeatedly a) truncate table b) insert into table .... c) select ... match .. against .. non-boolean/boolean mode After some time we could observe two different assert core dumps Analysis: -------- 1)assert core dump at key_read_cache(): Two select threads operating in-parallel on same key root block. 1st select thread block->status is set to BLOCK_ERROR because the my_pread() in read_block() is returning '0'. Truncate table made the index file size as 1024 and pread was asked to get the block of count bytes(1024 bytes) from offset of 1024 which it cannot read since its "end of file" and retuning '0' setting "my_errno= HA_ERR_FILE_TOO_SHORT" and the key_file_length, key_root[0] is same i.e. 1024. Since block status has BLOCK_ERROR the 1st select thread enter into the free_block() and will be under wait on conditional mutex by making status as BLOCK_REASSIGNED and goes for wait_on_readers(). Other select thread will also work on the same block and sees the status as BLOCK_ERROR and enters into free_block(), checks for BLOCK_REASSIGNED and asserting the server. 2)assert core dump at key_write_cache(): One select thread and One insert thread. Select thread gets the unlocks the 'keycache->cache_lock', which allows other threads to continue and gets the pread() return value as'0'(please see the explanation above) and tries to get the lock on 'keycache->cache_lock' and waits there for the lock. Insert thread requests for the block, block will be assigned from the hash list and makes the page_status as 'PAGE_WAIT_TO_BE_READ' and goes for the read_block(), waits in the queue since there are some other threads performing reads on the same block. Select thread which was waiting for the 'keycache->cache_lock' mutex in the read_block() will continue after getting the my_pread() value as '0' and sets the block status as BLOCK_ERROR and goes to the free_block() and go to the wait_for_readers(). Now the insert thread will awake and continues. and checks block->status as not BLOCK_READ and it asserts. Fix: --- In the full text code, multiple readers of index file is not guarded. Hence added below below code in _ft2_search() and walk_and_match(). to lock the key_root I have used below code in _ft2_search() if (info->s->concurrent_insert) mysql_rwlock_rdlock(&share->key_root_lock[0]); and to unlock if (info->s->concurrent_insert) mysql_rwlock_unlock(&share->key_root_lock[0]); storage/myisam/ft_boolean_search.c: Since its a recursion function, to avoid confusion in taking and releasing the locks, renamed _ft2_search() to _ft2_search_internal() function. And _ft2_search() will take the lock, call _ft2_search_internal() and release the lock in case of concurrent inserts. storage/myisam/ft_nlq_search.c: Added read locks code in walk_and_match()	14 years ago
Annamalai Gurusami	bcb5d73767	Bug #12752572 61579: REPLICATION FAILURE WHILE INNODB_AUTOINC_LOCK_MODE=1 AND USING TRIGGER When an insert stmt like "insert into t values (1),(2),(3)" is executed, the autoincrement values assigned to these three rows are expected to be contiguous. In the given lock mode (innodb_autoinc_lock_mode=1), the auto inc lock will be released before the end of the statement. So to make the autoincrement contiguous for a given statement, we need to reserve the auto inc values at the beginning of the statement. rb://1074 approved by Alexander Nozdrin	14 years ago
Nuno Carvalho	5d8b38df4c	BUG#11754117 - 45670: INTVAR_EVENTS FOR FILTERED-OUT QUERY_LOG_EVENTS ARE EXECUTED Improved random number filtering verification on rpl_filter_tables_not_exist test.	14 years ago
Marko Mäkelä	5917c58a5d	Bug#14025221 FOREIGN KEY REFERENCES FREED MEMORY AFTER DROP INDEX dict_table_replace_index_in_foreign_list(): Replace the dropped index also in the foreign key constraints of child tables that are referencing this table. row_ins_check_foreign_constraint(): If the underlying index is missing, refuse the operation. rb:1051 approved by Jimmy Yang	14 years ago
Georgi Kodinov	fcb033053d	Bug #11761822 : yassl rejects valid certificate which openssl accepts Applied the fix that updates yaSSL to 2.2.1 and fixes parsing this particular certificate. Added a test case with the certificate itself.	14 years ago
Bjorn Munch	e72278fd42	Added some extra optional path to test suites	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
Sunanda Menon	074ce71e90	Merge from mysql-5.1.63-release	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
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	1a2cf649dc	InnoDB: Adjust error message when a dropped tablespace is accessed.	14 years ago
Andrei Elkin	f189ccf530	merge from 5.1 repo	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
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	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	892106db92	new header file must be listed in Makefile.am	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
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	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
Georgi Kodinov	b61d6be9fd	Raise version number after cloning 5.1.63	14 years ago
Georgi Kodinov	df905524b2	merge mysql-5.1->mysql-5.1-security	14 years ago

1 2 3 4 5 ...

64365 Commits (e3c8fb4a1cf2984cf1aa1fe31ba828de550f619c) All Branches Search

64365 Commits (e3c8fb4a1cf2984cf1aa1fe31ba828de550f619c)

All Branches