mariadb

Commit Graph

Author	SHA1	Message	Date
Sergey Glukhov	63bca358ca	Bug#37284 Crash in Field_string::type() The bug is repeatable with latest(1.0.1) InnoDB plugin on Linux, Win, If MySQL is compiled with valgrind there are errors about using of uninitialized variable(orig_table). The fix is to set field->orig_table correct value.	17 years ago
Build Team	366adeab08	Added "Sun Microsystems, Inc." to copyright headers on files modified since Oct 1st	17 years ago
Georgi Kodinov	a0e3001cdb	Bug #33811 : Call to stored procedure with SELECT * / RIGHT JOIN fails after the first time Two separate problems : 1. When flattening joins the linked list used for name resolution (next_name_resolution_table) was not updated. Fixed by updating the pointers when extending the table list 2. The items created by expanding a * (star) as a column reference were marked as fixed, but no cached table was assigned to them (unlike what Item_field::fix_fields does). Fixed by assigning a cached table (so the re-preparation is done faster). Note that the fix for #2 hides the fix for #1 in most cases (except when a table reference cannot be cached).	17 years ago
Sergey Glukhov	38d90d60ab	Bug#35068 Assertion fails when reading from i_s.tables and there is incorrect merge table Hide "Table doesn't exist" errors if the table belongs to a merge table.	17 years ago
Gleb Shchepa	e219979e7d	Bug #38691 : segfault/abort in ``UPDATE ...JOIN'' while ``FLUSH TABLES WITH READ LOCK'' Concurrent execution of 1) multitable update with a NATURAL/USING join and 2) a such query as "FLUSH TABLES WITH READ LOCK" or "ALTER TABLE" of updating table led to a server crash. The mysql_multi_update_prepare() function call is optimized to lock updating tables only, so it postpones locking to the last, and if locking fails, it does cleanup of modified syntax structures and repeats a query analysis. However, that cleanup procedure was incomplete for NATURAL/USING join syntax data: 1) some Field_item items pointed into freed table structures, and 2) the TABLE_LIST::join_columns fields was not reset. Major change: short-living Field Natural_join_column::table_field has been replaced with long-living Item.	17 years ago
Davi Arnaut	f18e43502e	Wrap function used for debugging with the DBUG_OFF condition. Function uses a variable only available under debug mode.	17 years ago
Davi Arnaut	787fa9325f	Remove usage of the _db_strict_keyword_ in favor of the more reliable DBUG_EXECUTE_IF macro. The usage of the former caused breakage in other trees as it got removed from the dbug library.	17 years ago
Davi Arnaut	35ffaf10e3	Bug#34306: Can't make copy of log tables when server binary log is enabled The problem is that when statement-based replication was enabled, statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE .. SELECT FROM need to grab a read lock on the source table that does not permit concurrent inserts, which would in turn be denied if the source table is a log table because log tables can't be locked exclusively. The solution is to not take such a lock when the source table is a log table as it is unsafe to replicate log tables under statement based replication. Furthermore, the read lock that does not permits concurrent inserts is now only taken if statement-based replication is enabled and if the source table is not a log table.	17 years ago
Gleb Shchepa	db1d38c910	Bug#26020: User-Defined Variables are not consistent with columns data types The "SELECT @lastId, @lastId := Id FROM t" query returns different result sets depending on the type of the Id column (INT or BIGINT). Note: this fix doesn't cover the case when a select query references an user variable and stored function that updates a value of that variable, in this case a result is indeterminate. The server uses incorrect assumption about a constantness of an user variable value as a select list item: The server caches a last query number where that variable was changed and compares this number with a current query number. If these numbers are different, the server guesses, that the variable is not updating in the current query, so a respective select list item is a constant. However, in some common cases the server updates cached query number too late. The server has been modified to memorize user variable assignments during the parse phase to take them into account on the next (query preparation) phase independently of the order of user variable references/assignments in a select item list.	17 years ago
Martin Hansson	a43242ea6d	Bug#36086: SELECT * from views don't check column grants This patch also fixes bugs 36963 and 35600. - In many places a view was confused with an anonymous derived table, i.e. access checking was skipped. Fixed by introducing a predicate to tell the difference between named and anonymous derived tables. - When inserting fields for "SELECT * ", there was no distinction between base tables and views, where one should be made. View privileges are checked elsewhere.	17 years ago
Alexander Barkov	b25b2b2411	Additional fix for bug#31455 (rpl decoder) - Implementing --base64-format=decode-rows, to display SQL-alike decoded row events without their BINLOG statements. - Adding --base64-format=decode-rows into tests when calling mysqlbinlog to avoid non-deterministic results - Removing resetting of last_table_id in "RESET MASTER", which appeared to be dangerous.	17 years ago
Alexander Barkov	a57aa6bb75	Bug#31455 mysqlbinlog don't print user readable info about RBR events Implementing -v command line parameter to mysqlbinlog to decode and print row events. mysql-test/include/mysqlbinlog_row_engine.inc mysql-test/r/mysqlbinlog_row.result mysql-test/r/mysqlbinlog_row_big.result mysql-test/r/mysqlbinlog_row_innodb.result mysql-test/r/mysqlbinlog_row_myisam.result mysql-test/r/mysqlbinlog_row_trans.result mysql-test/t/mysqlbinlog_row.test mysql-test/t/mysqlbinlog_row_big.test mysql-test/t/mysqlbinlog_row_innodb.test mysql-test/t/mysqlbinlog_row_myisam.test mysql-test/t/mysqlbinlog_row_trans.test Adding tests client/Makefile.am Adding new files to symlink client/mysqlbinlog.cc Adding -v option sql/log_event.cc Impelentations of the new methods sql/log_event.h Declaration of the new methods and member sql/mysql_priv.h Adding new function prototype sql/rpl_tblmap.cc Adding pre-processor conditions sql/rpl_tblmap.h Adding pre-processor conditions sql/rpl_utility.h Adding pre-processor conditions sql/sql_base.cc Adding reset_table_id_sequence() function. sql/sql_repl.cc Resetting table_id on "RESET MASTER" .bzrignore Ignoring new symlinked files	17 years ago
Kristofer Pettersson	5c1f8d1836	Bug#38002 table_cache consumes too much memory with blobs Tables in the table definition cache are keeping a cache buffer for blob fields which can consume a lot of memory. This patch introduces a maximum size threshold for these buffers.	18 years ago
kostja@bodhi.(none)	6e4af99f5d	Bug#27430 "Crash in subquery code when in PS and table DDL changed after PREPARE": rename members, methods, classes to follow the spec (a code review request)	18 years ago
davi@skynet.(none)	2f770c91d2	Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE Add test target to the makefile that will cause all statements to be re-prepared before execution.	18 years ago
kostja@bodhi.(none)	7aeeb8f667	Implement some code review fixes for the fix for Bug#27430 "Crash in subquery code when in PS and table DDL changed after PREPARE"	18 years ago
mats@mats-laptop.(none)	812fa8b24c	BUG#36197: flush tables (or little table cache) can cause crash on slave When flushing tables, there were a slight chance that the flush was occuring between processing of two table map events. Since the tables are opened one by one, it might result in that the tables were not valid and that sub- sequent locking of tables would cause the slave to crash. The problem is solved by opening and locking all tables at once using simple_open_n_lock_tables(). Also, the patch contain a change to open_tables() so that pre-locking only takes place when the trg_event_map is not zero, which was not the case before (this caused the lock to be placed in thd->locked_tables instead of thd->lock since the assumption was that triggers would be called later and therefore the tables should be pre-locked).	18 years ago
kostja@dipika.(none)	d1f9376229	Tentative implementation of WL#4165 Prepared statements: validation WL#4166 Prepared statements: automatic re-prepare Fixes Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes Bug#27420 A combination of PS and view operations cause error + assertion on shutdown The basic idea of the patch is to keep track of table metadata between prepared statement prepare and execute. If some table used in the statement has changed, the prepared statement is re-prepared before execution. See WL#4165 and WL#4166 contents and comments in the code for details of the implementation.	18 years ago
kostja@dipika.(none)	ad4113f72f	Remove some unused code.	18 years ago
gkodinov/kgeorge@macbook.gmz	ff0aac178d	Bug #26461 : Intrinsic data type bool (1 byte) redefined to BOOL (4 bytes) The bool data type was redefined to BOOL (4 bytes on windows). Removed the #define and fixed some of the warnings that were uncovered by this. Note that the fix also disables 2 warnings : 4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning) 4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation These warnings will be handled in a separate bug, as they are performance related or bogus. Fixed to int the return type of functions that return more than 2 distinct values.	18 years ago
mattiasj@witty.	d918fa6ec9	Valgrind warnings found after bug#32943 and after merge from -main into -engines tree. hander::table_share was not updated after changing table->s.	18 years ago
gluh@mysql.com/mgluh.(none)	4f0873c04b	Bug#23588 SHOW COLUMNS on a temporary table causes locking issues skip lock_type update for temporary tables	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)	b46ce80902	A fix and a test case for Bug#34166 Server crash in SHOW OPEN TABLES and pre-locking. The crash was caused by an implicit assumption in check_table_access() that table_list parameter is always a part of lex->query_tables. When iterating over the passed list of tables, check_table_access() used to stop only when lex->query_tables_last_not_own was reached. In case of pre-locking, lex->query_tables_last_own is not NULL and points to some element of lex->query_tables. When the parameter of check_table_access() was not part of lex->query_tables, loop invariant could never be violated and a crash would happen when the current table pointer would point beyond the end of the provided list. The fix is to change the signature of check_table_access() to also accept a numeric limit of loop iterations, similarly to check_grant(), and supply this limit in all places when we want to check access of tables that are outside lex->query_tables, or just want to check access to one table.	18 years ago
gkodinov/kgeorge@macbook.gmz	2fc45f017d	Bug #33133 : Views are not transparent When resolving references we need to take into consideration the view "fields" and allow qualified access to them. Fixed by extending the reference resolution to process view fields correctly.	18 years ago
kostja@bodhi.(none)	dfe685e6fc	A pre-requisite for the fix for Bug#12713 "Error in a stored function called from a SELECT doesn't cause ROLLBACK of state" Make private all class handler methods (PSEA API) that may modify data. Introduce and deploy public ha_* wrappers for these methods in all sql/. This necessary to keep track of all data modifications in sql/, which is in turn necessary to be able to optimize two-phase commit of those transactions that do not modify data.	18 years ago
davi@mysql.com/endora.local	137e90ed55	Bug#32395 Alter table under a impending global read lock causes a server crash The problem is that some DDL statements (ALTER TABLE, CREATE TRIGGER, FLUSH TABLES, ...) when under LOCK TABLES need to momentarily drop the lock, reopen the table and grab the write lock again (using reopen_tables). When grabbing the lock again, reopen_tables doesn't pass a flag to mysql_lock_tables in order to ignore the impending global read lock, which causes a assertion because LOCK_open is being hold. Also dropping the lock must not signal to any threads that the table has been relinquished (related to the locking/flushing protocol). The solution is to correct the way the table is reopenned and the locks grabbed. When reopening the table and under LOCK TABLES, the table version should be set to 0 so other threads have to wait for the table. When grabbing the lock, any other flush should be ignored because it's theoretically a atomic operation. The chosen solution also fixes a potential discrepancy between binlog and GRL (global read lock) because table placeholders were being ignored, now a FLUSH TABLES WITH READ LOCK will properly for table with open placeholders. It's also important to mention that this patch doesn't fix a potential deadlock if one uses two GRLs under LOCK TABLES concurrently.	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
istruewing@stella.local	55aa6376f1	Bug#30273 - merge tables: Can't lock file (errno: 155) The patch for Bug 26379 (Combination of FLUSH TABLE and REPAIR TABLE corrupts a MERGE table) fixed this bug too. However it revealed a new bug that crashed the server. Flushing a merge table at the moment when it is between open and attach of children crashed the server. The flushing thread wants to abort locks on the flushed table. It calls ha_myisammrg::lock_count() and ha_myisammrg::store_lock() on the TABLE object of the other thread. Changed ha_myisammrg::lock_count() and ha_myisammrg::store_lock() to accept non-attached children. ha_myisammrg::lock_count() returns the number of MyISAM tables in the MERGE table so that the memory allocation done by get_lock_data() is done correctly, even if the children become attached before ha_myisammrg::store_lock() is called. ha_myisammrg::store_lock() will not return any lock if the children are not attached. This is however a change in the handler interface. lock_count() can now return a higher number than store_lock() stores locks. This is more safe than the reverse implementation would be. get_lock_data() in the SQL layer is adjusted accordingly. It sets MYSQL_LOCK::lock_count based on the number of locks returned by the handler::store_lock() calls, not based on the numbers returned by the handler::lock_count() calls. The latter are only used for allocation of memory now. No test case. The test suite cannot reliably run FLUSH between lock_count() and store_lock() of another thread. The bug report contains a program that can repeat the problem with some probability.	18 years ago
davi@mysql.com/endora.local	d179bb64c2	Bug#23713 LOCK TABLES + CREATE TRIGGER + FLUSH TABLES WITH READ LOCK = deadlock This bug is actually two bugs in one, one of which is CREATE TRIGGER under LOCK TABLES and the other is CREATE TRIGGER under LOCK TABLES simultaneous to a FLUSH TABLES WITH READ LOCK (global read lock). Both situations could lead to a server crash or deadlock. The first problem arises from the fact that when under LOCK TABLES, if the table is in the set of locked tables, the table is already open and it doesn't need to be reopened (not a placeholder). Also in this case, if the table is not write locked, a exclusive lock can't be acquired because of a possible deadlock with another thread also holding a (read) lock on the table. The second issue arises from the fact that one should never wait for a global read lock if it's holding any locked tables, because the global read lock is waiting for these tables and this leads to a circular wait deadlock. The solution for the first case is to check if the table is write locked and upgraded the write lock to a exclusive lock and fail otherwise for non write locked tables. Grabbin the exclusive lock in this case also means to ensure that the table is opened only by the calling thread. The second issue is partly fixed by not waiting for the global read lock if the thread is holding any locked tables. The second issue is only partly addressed in this patch because it turned out to be much wider and also affects other DDL statements. Reported as Bug#32395	18 years ago
davi@endora.local	94e6e4ff44	Bug#31397 Inconsistent drop table behavior of handler tables. The problem is that DROP TABLE and other DDL statements failed to automatically close handlers associated with tables that were marked for reopen (FLUSH TABLES). The current implementation fails to properly discard handlers of dropped tables (that were marked for reopen) because it searches on the open handler tables list and using the current alias of the table being dropped. The problem is that it must not use the open handler tables list to search because the table might have been closed (marked for reopen) by a flush tables command and also it must not use the current table alias at all since multiple different aliases may be associated with a single table. This is specially visible when a user has two open handlers (using alias) of a same table and a flush tables command is issued before the table is dropped (see test case). Scanning the handler table list is also useless for dropping handlers associated with temporary tables, because temporary tables are not kept in the THD::handler_tables list. The solution is to simple scan the handlers hash table searching for, and deleting all handlers with matching table names if the reopen flag is not passed to the flush function, indicating that the handlers should be deleted. All matching handlers are deleted even if the associated the table is not open.	18 years ago
thek@adventure.(none)	1794242b24	Bug #31153 calling stored procedure crashes server if available memory is low When the server was out of memory it crashed because of invalid memory access. This patch adds detection for failed memory allocations and make the server output a proper error message.	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
gkodinov/kgeorge@magare.gmz	3384d3e96c	Bug #31562 : HAVING and lower case The columns in HAVING can reference the GROUP BY and SELECT columns. There can be "table" prefixes when referencing these columns. And these "table" prefixes in HAVING use the table alias if available. This means that table aliases are subject to the same storage rules as table names and are dependent on lower_case_table_names in the same way as the table names are. Fixed by : 1. Treating table aliases as table names and make them lowercase when printing out the SQL statement for view persistence. 2. Using case insensitive comparison for table aliases when requested by lower_case_table_names	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)	230604f33c	In ha_delete_table, use a standard mechanism to intercept the error message and convert it to a warning instead of direct manipulation with the thread error stack. Fix a bug in handler::print_erorr when a garbled message was printed for HA_ERR_NO_SUCH_TABLE. This is a pre-requisite patch for the fix for Bug#12713 Error in a stored function called from a SELECT doesn't cause ROLLBACK of statem	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
tnurnberg@mysql.com/white.intern.koehntopp.de	66047f1c16	Bug#31662: 'null' is shown as type of fields for view with bad definer, breaks mysqldump SHOW FIELDS FROM a view with no valid definer was possible (since fix for Bug#26817), but gave NULL as a field-type. This led to mysqldump-ing of such views being successful, but loading such a dump with the client failing. Patch allows SHOW FIELDS to give data-type of field in underlying table.	18 years ago
malff@lambda.hsd1.co.comcast.net.	2bc41b7e1e	Bug#30854 (Tables name show as binary in slave err msg on vm-win2003-64-b) The root cause of this defect is that a call to my_error() is using a 'LEX_STRING' parameter instead of a 'char*' This patch fixes the failing calls to my_error(), as well as similar calls found during investigation. This is a compiling bug (see the instrumentation in the bug report), no test cases provided.	18 years ago
istruewing@stella.local	672290b03d	Bug#31692 - binlog_killed.test crashes sometimes The server crashed when a thread was killed while locking the general_log table at statement begin. The general_log table is handled like a performance schema table. The state of open tables is saved and cleared so that this table seems to be the only open one. Then this table is opened and locked. After writing, the table is closed and the open table state is restored. Before restoring, however, it is asserted that there is no current table open. After locking the table, mysql_lock_tables() checks if the thread was killed in between. If so, it unlocks the table and returns an error. open_ltable() just returns with the error and leaves closing of the table to close_thread_tables(), which is called at statement end. open_performance_schema_table() did not take this into account. It assumed that a failed open_ltable() would not leave an open table behind. Fixed by closing thread tables after open_ltable() and before restore_backup_open_tables_state() if the thread was killed. No test case. It requires correctly timed parallel execution. Since this bug was detected by the test suite, it seems dispensable to add another test.	18 years ago
cmiller@zippy.cornsilk.net	dee842e093	Doxygenized comments.	18 years ago
davi@moksha.local	7252cbe1e0	Bug#31409 RENAME TABLE causes server crash or deadlock when used with HANDLER statements This deadlock occurs when a client issues a HANDLER ... OPEN statement that tries to open a table that has a pending name-lock on it by another client that also needs a name-lock on some other table which is already open and associated to a HANDLER instance owned by the first client. The deadlock happens because the open_table() function will back-off and wait until the name-lock goes away, causing a circular wait if some other name-lock is also pending for one of the open HANDLER tables. Such situation, for example, can be easily repeated by issuing a RENAME TABLE command in such a way that the existing table is already open as a HANDLER table by another client and this client tries to open a HANDLER to the new table name. The solution is to allow handler tables with older versions (marked for flush) to be closed before waiting for the name-lock completion. This is safe because no other name-lock can be issued between the flush and the check for pending name-locks. The test case for this bug is going to be committed into 5.1 because it requires a test feature only avaiable in 5.1 (wait_condition).	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
malff/marcsql@weblab.(none)	88091e8250	Bug#30712 (open_performance_schema_table() cause an open table leak on failures) Fixed open_performance_schema_table() and close_performance_schema_table() implementation and callers, to always execute balanced calls to: thd->reset_n_backup_open_tables_state(backup); thd->restore_backup_open_tables_state(backup);	18 years ago
gshchepa/uchum@gleb.loc	4a7fdf8611	Fixed bug #30396 . Recommit to 5.1.22. The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.	18 years ago
davi@moksha.local	fa7ba431df	Bug#29936 (Stored Procedure DML ignores low_priority_updates setting) This is a follow up for the patch for Bug#26162 "Trigger DML ignores low_priority_updates setting", where the stored procedure ignores the session setting of low_priority_updates.	19 years ago
davi@moksha.local	d669228006	Bug#29936 (Stored Procedure DML ignores low_priority_updates setting) This is a follow up for the patch for Bug#26162 "Trigger DML ignores low_priority_updates setting", where the stored procedure ignores the session setting of low_priority_updates. For every table open operation with default write (TL_WRITE_DEFAULT) lock_type, downgrade the lock type to the session setting of low_priority_updates.	19 years ago
tsmith@ramayana.hindu.god	49891223c3	Bug #29474 : 21587 Regression Ever increasing open tables/fd when using HANDLER READ + DELETE Revert the fix for bug 21587. That bug will be re-opened, and a new fix must be created.	19 years ago
igor@olga.mysql.com	d790ec42e1	Fixed bug #30396 . The bug caused memory corruption for some queries with top OR level in the WHERE condition if they contained equality predicates and other sargable predicates in disjunctive parts of the condition. The corruption happened because the upper bound of the memory allocated for KEY_FIELD and SARGABLE_PARAM internal structures containing info about potential lookup keys was calculated incorrectly in some cases. In particular it was calculated incorrectly when the WHERE condition was an OR formula with disjuncts being AND formulas including equalities and other sargable predicates.	19 years ago

1 2 3 4 5 ...

1252 Commits (9d8c117598092a05e92ae0921085bd2c511c744e)