mariadb

Commit Graph

Author	SHA1	Message	Date
Build Team	366adeab08	Added "Sun Microsystems, Inc." to copyright headers on files modified since Oct 1st	17 years ago
Georgi Kodinov	b204dc43cc	Bug #38693 : leaked memory with blobs! If delayed insert fails to upgrade the lock it was not freeing the temporary memory storage used to keep newly constructed blob values in memory. Fixed by iterating over the remaining rows in the delayed insert rowset and freeing the blob storage for each row. No test suite because it involves concurrent delayed inserts on a table and cannot easily be made deterministic. Added a correct valgrind suppression for Fedora 9.	17 years ago
Mats Kindahl	70b18065d0	Bug #34707 : Row based replication: slave creates table within wrong database The failure was caused by executing a CREATE-SELECT statement that creates a table in another database than the current one. In row-based logging, the CREATE statement was written to the binary log without the database, hence creating the table in the wrong database, causing the following inserts to fail since the table didn't exist in the given database. Fixed the bug by adding a parameter to store_create_info() that will make the function print the database name before the table name and used that in the calls that write the CREATE statement to the binary log. The database name is only printed if it is different than the currently selected database. The output of SHOW CREATE TABLE has not changed and is still printed without the database name.	17 years ago
Kristofer Pettersson	cc9b99a2e1	Bug#38692 concurrent inserts cause valgrind errors in Query_cache::invalidate Concurrent inserts produce valgrind error messages. The reason is that the query cache is invalidated after the target table object is closed. Since the delayed insert thread already takes care of invalidating the query cache there is no need to try to synchronize an extra cache invalidation call. The fix is to remove the query_cache_invalidate3 call altogether.	17 years ago
Narayanan V	83ef8f3427	Bug#38338: REPLACE causes last_insert_id() to return an incorrect value Fix the write_record function to record auto increment values in a consistent way.	17 years ago
Kristofer Pettersson	c01aeb1083	Bug#38692 concurrent inserts cause valgrind errors in Query_cache::invalidate If a delayed insert thread was aborted by a concurrent 'truncate table' statement, then the diagnostic area would fail with an assert in a debug build because no actual error message was pushed on the stack despite a thread being killed. This patch adds an error message to the stack.	17 years ago
Ramil Kalimullin	ef13c12c0a	Fix for bug#38821: Assert table->auto_increment_field_not_null failed in open_table() Problem: repeating "CREATE... ( AUTOINCREMENT) ... SELECT" may lead to an assertion failure. Fix: reset table->auto_increment_field_not_null after each record writing.	17 years ago
Andrei Elkin	44b82b3eca	Bug #38798 Assertion mysql_bin_log.is_open() failed in binlog_trans_log_savepos() The assert is about binlogging must have been activated, but it was not actually according to the reported how-to-repeat instuctions. Analysis revealed that binlog_start_trans_and_stmt() was called without prior testing if binlogging is ON. Fixed with avoing entering binlog_start_trans_and_stmt() if binlog is not activated.	17 years ago
Mats Kindahl	f0bf4a47ca	Bug #34707 : Row based replication: slave creates table within wrong database The failure was caused by executing a CREATE-SELECT statement that creates a table in another database than the current one. In row-based logging, the CREATE statement was written to the binary log without the database, hence creating the table in the wrong database, causing the following inserts to fail since the table didn't exist in the given database. Fixed the bug by adding a parameter to store_create_info() that will make the function print the database name before the table name and used that in the calls that write the CREATE statement to the binary log. The database name is only printed if it is different than the currently selected database. The output of SHOW CREATE TABLE has not changed and is still printed without the database name.	18 years ago
Mats Kindahl	2a089557a6	BUG#37426: RBR breaks for CHAR() UTF-8 fields > 85 chars In order to handle CHAR() fields, 8 bits were reserved for the size of the CHAR field. However, instead of denoting the number of characters in the field, field_length was used which denotes the number of bytes in the field. Since UTF-8 fields can have three bytes per character (and has been extended to have four bytes per character in 6.0), an extra two bits have been encoded in the field metadata work for fields of type Field_string (i.e., CHAR fields). Since the metadata word is filled, the extra bits have been encoded in the upper 4 bits of the real type (the most significant byte of the metadata word) by computing the bitwise xor of the extra two bits. Since the upper 4 bits of the real type always is 1111 for Field_string, this means that for fields of length <256, the encoding is identical to the encoding used in pre-5.1.26 servers, but for lengths of 256 or more, an unrecognized type is formed, causing an old slave (that does not handle lengths of 256 or more) to stop.	18 years ago
Mattias Jonsson	109a041a95	Bug#31210: INSERT DELAYED crashes server when used on partitioned tables Problem was an unclear error message since it could suggest that MyISAM did not support INSERT DELAYED. Changed the error message to say that DELAYED is not supported by the table, instead of the table's storage engine. The confusion is that a partitioned table is in somewhat sense using the partitioning storage engine, which in turn uses the ordinary storage engine. By saying that the table does not support DELAYED we do not give any extra informantion about the storage engine or if it is partitioned.	18 years ago
aelkin/andrei@mysql1000.(none)	725d07d559	Bug #35762 Failing CREATE-SELECT steels Table map of the following query Among two claimed artifacts the critical one is in that the Table map of a query following the failing with a duplicate key error CREATE-SELECT is skipped from instantionating (and thus binlogging). That leads to sending a "chopped" group of the data row-events without the table map head to the slave. The slave can not apply the only data row events. It's not easy to force the slave to react with an error in such a case (the second complaint on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event handler is a common situation which normally designates the event has to be filtered out basing on the repliation do/ingore rules decision. Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in select_create::abort(). No error is reported if by chance the table map was not been binlogged. Leaving this out to resolve with considering how to combine the do/ingore rules with the situation when erronoulsy the Table_map is not written to binlog.	18 years ago
mattiasj@witty.	b008ac3aac	Bug#21413 - Engine table handler used by multiple threads in REPLACE DELAYED post push patch, removing the optimization for copying delayed_insert variables.	18 years ago
mats@mats-laptop.(none)	c8c4500a98	BUG#29020 (Event results not correctly replicated to slave in RBR): The bug allow multiple executing transactions working with non-transactional to interfere with each others by interleaving the events of different trans- actions. Bug is fixed by writing non-transactional events to the transaction cache and flushing the cache to the binary log at statement commit. To mimic the behavior of normal statement-based replication, we flush the transaction cache in row- based mode when there is no committed statements in the transaction cache, which means we are committing the first one. This means that it will be written to the binary log as a "mini-transaction" with just the rows for the statement. Note that the changes here does not take effect when building the server with HAVE_TRANSACTIONS set to false, but it is not clear if this was possible before this patch either. For row-based logging, we also have that when AUTOCOMMIT=1, the code now always generates a BEGIN/COMMIT pair for single statements, or BEGIN/ROLLBACK pair in the case of non-transactional changes in a statement that was rolled back. Note that for the case where changes to a non-transactional table causes a rollback due to error, the statement will now be logged with a BEGIN/ROLLBACK pair, even though some changes has been committed to the non-transactional table.	18 years ago
mattiasj@witty.	c87874a1a3	Recommit of antonys previous commit. Bug#21413 "Engine table handler used by multiple threads in REPLACE DELAYED" When executing a REPLACE DELAYED statement, the storage engine ::extra() method was invoked by a different thread than the thread which has acquired the handler instance. This did not cause problems within the current server and with the current storage engines. But it has the potential to confuse future storage engines. Added code to avoid surplus calls to extra() method in case of DELAYED which avoids calling storage engine from a different thread than expected. No test case. This change does not change behavior in conjunction with current storage engines. So it cannot be tested by the regression test suite.	18 years ago
svoj@mysql.com/june.mysql.com	6dfb184f09	BUG#34768 - nondeterministic INSERT using LIMIT logged in stmt mode if binlog_format=mixed Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT, INSERT ... SELECT ... LIMIT is not safe as order of rows is not defined. With this fix, we issue a warning that this statement is not safe to replicate in statement mode, or go to row-based mode in mixed mode. Note that we may consider a statement as safe if ORDER BY primary_key is present. However it may confuse users to see very similiar statements replicated differently. Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but this patch doesn't address this issue. See comment from Kristian posted 18 Mar 10:55.	18 years ago
kaa@kaamos.(none)	80d89023ea	Fix for bug #34889 : mysql_client_test::test_mysql_insert_id test fails sporadically Under some circumstances, the mysql_insert_id() value after SELECT ... INSERT could return a wrong value. This could happen when the last SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the value of mysql_insert_id() was changed by some previous statements. Fixed by checking the value of thd->insert_id_used in select_insert::send_eof() and returning 0 for mysql_insert_id() if it is not set.	18 years ago
kostja@dipika.(none)	f106d9738a	Rename send_ok to my_ok. Similarly to my_error, it only records the status, does not send it to the client.	18 years ago
kostja@dipika.(none)	acf9b1f346	A fix and a test case for Bug#12713 "Error in a stored function called from a SELECT doesn't cause ROLLBACK of statem". The idea of the fix is to ensure that we always commit the current statement at the end of dispatch_command(). In order to not issue redundant disc syncs, an optimization of the two-phase commit protocol is implemented to bypass the two phase commit if the transaction is read-only.	18 years ago
kostja@dipika.(none)	8aa978352e	A minor cleanup.	18 years ago
evgen@moonbone.local	baaf300d4c	Bug#29477: Not all fields of the target table were checked to have a default value when inserting into a view. The mysql_prepare_insert function checks all fields of the target table that directly or indirectly (through a view) are specified in the INSERT statement to have a default value. This check can be skipped if the INSERT statement doesn't mention any insert fields. In case of a view this allows fields that aren't mentioned in the view to bypass the check. Now fields of the target table are always checked to have a default value when insert goes into a view.	18 years ago
kostja@bodhi.(none)	ebb9c5d983	Bug#12713 "Error in a stored function called from a SELECT doesn't cause ROLLBACK of statement", part 1. Review fixes. Do not send OK/EOF packets to the client until we reached the end of the current statement. This is a consolidation, to keep the functionality that is shared by all SQL statements in one place in the server. Currently this functionality includes: - close_thread_tables() - log_slow_statement(). After this patch and the subsequent patch for Bug#12713, it shall also include: - ha_autocommit_or_rollback() - net_end_statement() - query_cache_end_of_result(). In future it may also include: - mysql_reset_thd_for_next_command().	18 years ago
kaa@polly.(none)	24c9d86416	5.0 version of the fix for bug #9481 : mysql_insert_id() returns 0 after insert ... select. The 5.0 manual page for mysql_insert_id() does not mention anything about INSERT ... SELECT, though its current behavior is incosistent with what the manual says about the plain INSERT. Fixed by changing the AUTO_INCREMENT and mysql_insert_id() handling logic in INSERT ... SELECT to be consistent with the INSERT behavior, the manual, and the changes in 5.1 introduced by WL3146: - mysql_insert_id() now returns the first automatically generated AUTO_INCREMENT value that was successfully inserted by INSERT ... SELECT - if an INSERT ... SELECT statement is executed, and no automatically generated value is successfully inserted, mysql_insert_id() now returns the ID of the last inserted row.	18 years ago
ramil/ram@mysql.com/ramil.myoffice.izhnet.ru	5adf16e288	Fix for bug #32676 : insert delayed crash with wrong column and function specified Problem: using wrong local lock type value in the mysql_insert() results in a crash. Fix: use a proper value.	18 years ago
evgen@moonbone.local	da7470afb1	Bug#30384: Having SQL_BUFFER_RESULT option in the CREATE .. KEY(..) .. SELECT led to creating corrupted index. Corrected fix. The new method called prepare2 is added to the select_create class. As all preparations are done by the select_create::prepare function it doesn't do anything. Slightly changed algorithm of calling the start_bulk_insert function. Now it's called from the select_insert::prepare2 function when the SQL_BUFFER_RESULT flags is set. The is_bulk_insert_mode flag is removed as it is not needed anymore.	18 years ago
istruewing@stella.local	0605274155	Bug#26379 - Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Bug 26377 - Deadlock with MERGE and FLUSH TABLE Bug 25038 - Waiting TRUNCATE Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Bug 19627 - temporary merge table locking Bug 27660 - Falcon: merge table possible Bug 30273 - merge tables: Can't lock file (errno: 155) The problems were: Bug 26379 - Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table 1. A thread trying to lock a MERGE table performs busy waiting while REPAIR TABLE or a similar table administration task is ongoing on one or more of its MyISAM tables. 2. A thread trying to lock a MERGE table performs busy waiting until all threads that did REPAIR TABLE or similar table administration tasks on one or more of its MyISAM tables in LOCK TABLES segments do UNLOCK TABLES. The difference against problem #1 is that the busy waiting takes place after the administration task. It is terminated by UNLOCK TABLES only. 3. Two FLUSH TABLES within a LOCK TABLES segment can invalidate the lock. This does not require a MERGE table. The first FLUSH TABLES can be replaced by any statement that requires other threads to reopen the table. In 5.0 and 5.1 a single FLUSH TABLES can provoke the problem. Bug 26867 - LOCK TABLES + REPAIR + merge table result in memory/cpu hogging Trying DML on a MERGE table, which has a child locked and repaired by another thread, made an infinite loop in the server. Bug 26377 - Deadlock with MERGE and FLUSH TABLE Locking a MERGE table and its children in parent-child order and flushing the child deadlocked the server. Bug 25038 - Waiting TRUNCATE Truncating a MERGE child, while the MERGE table was in use, let the truncate fail instead of waiting for the table to become free. Bug 25700 - merge base tables get corrupted by optimize/analyze/repair table Repairing a child of an open MERGE table corrupted the child. It was necessary to FLUSH the child first. Bug 30275 - Merge tables: flush tables or unlock tables causes server to crash Flushing and optimizing locked MERGE children crashed the server. Bug 19627 - temporary merge table locking Use of a temporary MERGE table with non-temporary children could corrupt the children. Temporary tables are never locked. So we do now prohibit non-temporary chidlren of a temporary MERGE table. Bug 27660 - Falcon: merge table possible It was possible to create a MERGE table with non-MyISAM children. Bug 30273 - merge tables: Can't lock file (errno: 155) This was a Windows-only bug. Table administration statements sometimes failed with "Can't lock file (errno: 155)". These bugs are fixed by a new implementation of MERGE table open. When opening a MERGE table in open_tables() we do now add the child tables to the list of tables to be opened by open_tables() (the "query_list"). The children are not opened in the handler at this stage. After opening the parent, open_tables() opens each child from the now extended query_list. When the last child is opened, we remove the children from the query_list again and attach the children to the parent. This behaves similar to the old open. However it does not open the MyISAM tables directly, but grabs them from the already open children. When closing a MERGE table in close_thread_table() we detach the children only. Closing of the children is done implicitly because they are in thd->open_tables. For more detail see the comment at the top of ha_myisammrg.cc. Changed from open_ltable() to open_and_lock_tables() in all places that can be relevant for MERGE tables. The latter can handle tables added to the list on the fly. When open_ltable() was used in a loop over a list of tables, the list must be temporarily terminated after every table for open_and_lock_tables(). table_list->required_type is set to FRMTYPE_TABLE to avoid open of special tables. Handling of derived tables is suppressed. These details are handled by the new function open_n_lock_single_table(), which has nearly the same signature as open_ltable() and can replace it in most cases. In reopen_tables() some of the tables open by a thread can be closed and reopened. When a MERGE child is affected, the parent must be closed and reopened too. Closing of the parent is forced before the first child is closed. Reopen happens in the order of thd->open_tables. MERGE parents do not attach their children automatically at open. This is done after all tables are reopened. So all children are open when attaching them. Special lock handling like mysql_lock_abort() or mysql_lock_remove() needs to be suppressed for MERGE children or forwarded to the parent. This depends on the situation. In loops over all open tables one suppresses child lock handling. When a single table is touched, forwarding is done. Behavioral changes: =================== This patch changes the behavior of temporary MERGE tables. Temporary MERGE must have temporary children. The old behavior was wrong. A temporary table is not locked. Hence even non-temporary children were not locked. See Bug 19627 - temporary merge table locking. You cannot change the union list of a non-temporary MERGE table when LOCK TABLES is in effect. The following does not work: CREATE TABLE m1 ... ENGINE=MRG_MYISAM ...; LOCK TABLES t1 WRITE, t2 WRITE, m1 WRITE; ALTER TABLE m1 ... UNION=(t1,t2) ...; However, you can do this with a temporary MERGE table. You cannot create a MERGE table with CREATE ... SELECT, neither as a temporary MERGE table, nor as a non-temporary MERGE table. CREATE TABLE m1 ... ENGINE=MRG_MYISAM ... SELECT ...; Gives error message: table is not BASE TABLE.	18 years ago
istruewing@stella.local	3eaf82a175	Bug#31210 - INSERT DELAYED crashes server when used on partitioned table Trying INSERT DELAYED on a partitioned table, that has not been used right before, crashes the server. When a table is used for select or update, it is kept open for some time. This period I mean with "right before". Information about partitioning of a table is stored in form of a string in the .frm file. Parsing of this string requires a correctly set up lexical analyzer (lex). The partitioning code uses a new temporary instance of a lex. But it does still refer to the previously active lex. The delayd insert thread does not initialize its lex though... Added initialization for thd->lex before open table in the delayed thread and at all other places where it is necessary to call lex_start() if all tables would be partitioned and need to parse the .frm file.	18 years ago
davi@endora.local	cc007acb78	Bug#30882 Dropping a temporary table inside a stored function may cause a server crash If a stored function that contains a drop temporary table statement is invoked by a create temporary table of the same name may cause a server crash. The problem is that when dropping a table no check is done to ensure that table is not being used by some outer query (or outer statement), potentially leaving the outer query with a reference to a stale (freed) table. The solution is when dropping a temporary table, always check if the table is being used by some outer statement as a temporary table can be dropped inside stored procedures. The check is performed by looking at the TABLE::query_id value for temporary tables. To simplify this check and to solve a bug related to handling of temporary tables in prelocked mode, this patch changes the way in which this member is used to track the fact that table is used/unused. Now we ensure that TABLE::query_id is zero for unused temporary tables (which means that all temporary tables which were used by a statement should be marked as free for reuse after it's execution has been completed).	18 years ago
kostja@bodhi.(none)	e4b353c40c	Use an inline getter method (thd->is_error()) to query if there is an error in THD. In future the error may be stored elsewhere (not in net.report_error) and it's important to start using an opaque getter to simplify merges.	18 years ago
aelkin/elkin@koti.dsl.inet.fi	01f86563cb	Manual merge 5.0-rpl -> 5.1-rpl. involved bug#12691, bug#27571	18 years ago
aelkin/elkin@koti.dsl.inet.fi	27436f0ba3	Bug #27571 asynchronousity in setting mysql_`query`::error and Query_log_event::error_code A query can perform completely having the local var error of mysql_$query zero, where $query in insert, update, delete, load, and be binlogged with error_code e.g KILLED_QUERY while there is no reason do to so. That can happen because Query_log_event consults thd->killed flag to evaluate error_code. Fixed with implementing a scheme suggested and partly implemented at time of bug@22725 work-on. error_status is cached immediatly after the control leaves the main rows-loop and that instance always corresponds to `error' the local of mysql_$query functions. The cached value is passed to Query_log_event constructor, not the default thd->killed which can be changed in between of the caching and the constructing.	18 years ago
davi@moksha.local	f3b6d56fb2	The fix for BUG 21136 (ChangeSet@1.2611.1.1) introduced a regression that caused a few tests to fail because the thd->extra_lock wasn't being set to NULL after the table was unlocked. This poses a serious problem because later attempts to access thd->extra_lock (now a dangling pointer) will probably result in a crash (undefined behavior) -- and that's what actually happens in some test cases. The solution is to set the select_create::m_plock pointee to NULL, which means that thd->extra_lock is set to NULL when the lock data is not for a temporary table.	18 years ago
davi@moksha.local	ae079ec427	Bug#21136 CREATE TABLE SELECT within CREATE TABLE SELECT causes server crash When CREATE TEMPORARY TABLE .. SELECT is invoked from a stored function which in turn is called from CREATE TABLE SELECT causes a memory leak because the inner create temporary table overrides the outter extra_lock reference when locking the table. The solution is to simply not overrride the extra_lock by only using the extra_lock for a non-temporary table lock.	18 years ago
gkodinov/kgeorge@magare.gmz	fb3b12176d	Bug #30468 : column level privileges not respected when joining tables When expanding a * in a USING/NATURAL join the check for table access for both tables in the join was done using the grant information of the first one. Fixed by getting the grant information for the current table while iterating through the columns of the join.	18 years ago
gkodinov/kgeorge@magare.gmz	d0b796bf14	merge of the fix for bug 27802 & 27216 to 5.1-opt	18 years ago
evgen@sunlight.local	36bf417b40	Bug#27216: functions with parameters of different date types may return wrong type of the result. There are several functions that accept parameters of different types. The result field type of such functions was determined based on the aggregated result type of its arguments. As the DATE and the DATETIME types are represented by the STRING type, the result field type of the affected functions was always STRING for DATE/DATETIME arguments. The affected functions are COALESCE, IF, IFNULL, CASE, LEAST/GREATEST, CASE. Now the affected functions aggregate the field types of their arguments rather than their result types and return the result of aggregation as their result field type. The cached_field_type member variable is added to the number of classes to hold the aggregated result field type. The str_to_date() function's result field type now defaults to the MYSQL_TYPE_DATETIME. The agg_field_type() function is added. It aggregates field types with help of the Field::field_type_merge() function. The create_table_from_items() function now uses the item->tmp_table_field_from_field_type() function to get the proper field when the item is a function with a STRING result type.	18 years ago
evgen@sunlight.local	bb5cdfb87e	Bug#30384: Having SQL_BUFFER_RESULT option in the CREATE .. KEY(..) .. SELECT led to creating corrupted index. While execution of the CREATE .. SELECT SQL_BUFFER_RESULT statement the engine->start_bulk_insert function was called twice. On the first call On the first call MyISAM disabled all non-unique indexes and on the second call it decides to not re-enable them because all indexes was disabled. Due to this no indexes was actually created during CREATE TABLE thus producing crashed table. Now the select_inset class has is_bulk_insert_mode flag which prevents calling the start_bulk_insert function twice. The flag is set in the select_create::prepare, select_insert::prepare2 functions and the select_insert class constructor. The flag is reset in the select_insert::send_eof function.	18 years ago
aelkin@dl145j.mysql.com	11c9a13a24	Merge: bug#27417,23333 manual work for fixing tests and a source code.	18 years ago
davi@moksha.local	1180c22aef	Bug#28587 SELECT is blocked by INSERT waiting on read lock, even with low_priority_updates The problem is that a SELECT on one thread is blocked by INSERT ... ON DUPLICATE KEY UPDATE on another thread even when low_priority_updates is activated. The solution is to possibly downgrade the lock type to the setting of low_priority_updates if the INSERT cannot be concurrent.	19 years ago
thek@adventure.(none)	b1b2108275	Bug#27358 INSERT DELAYED does not honour SQL_MODE of the client SQL_MODE was ignored when a client issued INSERT DELAYED. Some system settings weren't copied as intended when a record was saved for a delayed insert.	19 years ago
aelkin/elkin@dsl-hkibras-fe38f900-157.dhcp.inet.fi	77998c30c2	Bug #23333 stored function + non-transac table + transac table = breaks stmt-based binlog Binlogging of the statement with a side effect like a modified non-trans table did not happen. The artifact involved all binloggable dml queries. Fixed with changing the binlogging conditions all over the code to exploit thd->transaction.stmt.modified_non_trans_table introduced by the patch for bug@27417. Multi-delete case has own specific addressed by another bug@29136. Multi-update case has been addressed by bug#27716 and patch and will need merging.	19 years ago
monty@mysql.com/nosik.monty.fi	e53a73e26c	Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris Faster thr_alarm() Added 'Opened_files' status variable to track calls to my_open() Don't give warnings when running mysql_install_db Added option --source-install to mysql_install_db I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems index_read() -> index_read_map() index_read_idx() -> index_read_idx_map() index_read_last() -> index_read_last_map()	19 years ago
svoj@mysql.com/april.(none)	2c539642c0	BUG#29152 - INSERT DELAYED does not use concurrent_insert on slave INSERT DELAYED on a replication slave was converted to regular INSERT, whereas it should try concurrent INSERT first. With this patch we try to convert delayed insert to concurrent insert on a replication slave. If it is impossible for some reason, we fall back to regular insert. No test case for this fix. I do not see anything indicating this is regression - we behave this way since Nov 2000.	19 years ago
gkodinov/kgeorge@magare.gmz	992698ce5f	merge of the fix for bug 17417 5.0-opt->5.1-opt	19 years ago
gkodinov/kgeorge@magare.gmz	9a0e6ec6d2	(pushing for Andrei) Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack Once had been set the flag might later got reset inside of a stored routine execution stack. The reason was in that there was no check if a new statement started at time of resetting. The artifact affects most of binlogable DML queries. Notice, that multi-update is wrapped up within bug@27716 fix, multi-delete bug@29136. Fixed with saving parent's statement flag of whether the statement modified non-transactional table, and unioning (merging) the value with that was gained in mysql_execute_command. Resettling thd->no_trans_update members into thd->transaction.`member`; Asserting code; Effectively the following properties are held. 1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table reflects the fact if such a table got modified by the substatement. That also respects THD::really_abort_on_warnin() requirements. 2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as the union of the values of all invoked sub-statements. That fixes this bug#27417; Computing of thd->transaction.all.modified_non_trans_table is refined to base to the stmt's value for all the case including insert .. select statement which before the patch had an extra issue bug@28960. Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in to temp_table select. The supplied test verifies limitely, mostly asserts. The ultimate testing is defered for bug@13270, bug@23333.	19 years ago
monty@mysql.com/nosik.monty.fi	b16289a5e0	Slow query log to file now displays queries with microsecond precission --long-query-time is now given in seconds with microseconds as decimals --min_examined_row_limit added for slow query log long_query_time user variable is now double with 6 decimals Added functions to get time in microseconds Added faster time() functions for system that has gethrtime() (Solaris) We now do less time() calls. Added field->in_read_set() and field->in_write_set() for easier field manipulation by handlers set_var.cc and my_getopt() can now handle DOUBLE variables. All time() calls changed to my_time() my_time() now does retry's if time() call fails. Added debug function for stopping in mysql_admin_table() when tables are locked Some trivial function and struct variable renames to avoid merge errors. Fixed compiler warnings Initialization of some time variables on windows moved to my_init()	19 years ago
malff/marcsql@weblab.(none)	c7bbd8917c	WL#3984 (Revise locking of mysql.general_log and mysql.slow_log) Bug#25422 (Hang with log tables) Bug 17876 (Truncating mysql.slow_log in a SP after using cursor locks the thread) Bug 23044 (Warnings on flush of a log table) Bug 29129 (Resetting general_log while the GLOBAL READ LOCK is set causes a deadlock) Prior to this fix, the server would hang when performing concurrent ALTER TABLE or TRUNCATE TABLE statements against the LOG TABLES, which are mysql.general_log and mysql.slow_log. The root cause traces to the following code: in sql_base.cc, open_table() if (table->in_use != thd) { /* wait_for_condition will unlock LOCK_open for us */ wait_for_condition(thd, &LOCK_open, &COND_refresh); } The problem with this code is that the current implementation of the LOGGER creates 'fake' THD objects, like - Log_to_csv_event_handler::general_log_thd - Log_to_csv_event_handler::slow_log_thd which are not associated to a real thread running in the server, so that waiting for these non-existing threads to release table locks cause the dead lock. In general, the design of Log_to_csv_event_handler does not fit into the general architecture of the server, so that the concept of general_log_thd and slow_log_thd has to be abandoned: - this implementation does not work with table locking - it will not work with commands like SHOW PROCESSLIST - having the log tables always opened does not integrate well with DDL operations / FLUSH TABLES / SET GLOBAL READ_ONLY With this patch, the fundamental design of the LOGGER has been changed to: - always open and close a log table when writing a log - remove totally the usage of fake THD objects - clarify how locking of log tables is implemented in general. See WL#3984 for details related to the new locking design. Additional changes (misc bugs exposed and fixed): 1) mysqldump which would ignore some tables in dump_all_tables_in_db(), but forget to ignore the same in dump_all_views_in_db(). 2) mysqldump would also issue an empty "LOCK TABLE" command when all the tables to lock are to be ignored (numrows == 0), instead of not issuing the query. 3) Internal errors handlers could intercept errors but not warnings (see sql_error.cc). 4) Implementing a nested call to open tables, for the performance schema tables, exposed an existing bug in remove_table_from_cache(), which would perform: in_use->some_tables_deleted=1; against another thread, without any consideration about thread locking. This call inside remove_table_from_cache() was not required anyway, since calling mysql_lock_abort() takes care of aborting -- cleanly -- threads that might hold a lock on a table. This line (in_use->some_tables_deleted=1) has been removed.	19 years ago
gkodinov/kgeorge@magare.gmz	02fe5e27d2	Bug #29571 : INSERT DELAYED IGNORE written to binary log on the master but on the slave MySQL can decide to "downgrade" a INSERT DELAYED statement to normal insert in certain situations. One such situation is when the slave is replaying a replication feed. However INSERT DELAYED is logged even if there're no updates whereas the NORMAL INSERT is not logged in such cases. Fixed by always logging a "downgraded" INSERT DELAYED: even if there were no updates.	19 years ago
kostja@bodhi.(none)	4c7d2df910	A follow-up fix for Bug#29431 "killing an insert delayed thread causes crash" in 5.1	19 years ago
kostja@bodhi.(none)	c4bcce64a4	Rename all references to 'Delayed_insert' instances from 'tmp' to 'di' for consistency.	19 years ago

1 2 3 4 5 ...

906 Commits (2cc7e72aaa813cfe368fab27846d1b7801082561)