mariadb

Commit Graph

Author	SHA1	Message	Date
jani@ua141d10.elisa.omakaista.fi	5c542a4656	Fixed compiler warnings.	19 years ago
tsmith@quadxeon.mysql.com	21ed11cda2	Bug #27231 : Server crash when dumping into outfile with long FIELDS ENCLOSED BY option - Problem: data separators were copied to a fixed-size buffer on the stack; memcpy was used, without bounds checking; a server crash could result if long FIELDS ENCLOSED BY, etc., was given - Fix: write the separators directly, instead of copying to a buffer first (in select_export::send_data())	19 years ago
mats@romeo.(none)	b1f69b48ef	BUG#26969: Field_bit::pack() and Field_bit::unpack() does not work correctly Fixing code for Field_bit packing and unpacking to work with arbitrary pointers instead of requiring Field::ptr	19 years ago
cbell/Chuck@mysql_cab_desk.	d44eb9f0c9	Bug #25543 Replication of wrong values if using rand() in stored procedure When rand() is called multiple times inside a stored procedure, the server does not binlog the correct random seed values. This patch corrects the problem by resetting rand_used= 0 in THD::cleanup_after_query() allowing the system to save the random seeds if needed for each command in a stored procedure body. However, rand_used is not reset if executing in a stored function or trigger because these operations are binlogged by call and thus only the calling statement need detect the call to rand() made by its substatements. These substatements must not set rand_used to 0 because it would remove the detection of rand() by the calling statement.	19 years ago
kostja@bodhi.local	86f02cd378	A fix for Bug#26750 "valgrind leak in sp_head" (and post-review fixes). The legend: on a replication slave, in case a trigger creation was filtered out because of application of replicate-do-table/ replicate-ignore-table rule, the parsed definition of a trigger was not cleaned up properly. LEX::sphead member was left around and leaked memory. Until the actual implementation of support of replicate-ignore-table rules for triggers by the patch for Bug 24478 it was never the case that "case SQLCOM_CREATE_TRIGGER" was not executed once a trigger was parsed, so the deletion of lex->sphead there worked and the memory did not leak. The fix: The real cause of the bug is that there is no 1 or 2 places where we can clean up the main LEX after parse. And the reason we can not have just one or two places where we clean up the LEX is asymmetric behaviour of MYSQLparse in case of success or error. One of the root causes of this behaviour is the code in Item::Item() constructor. There, a newly created item adds itself to THD::free_list - a single-linked list of Items used in a statement. Yuck. This code is unaware that we may have more than one statement active at a time, and always assumes that the free_list of the current statement is located in THD::free_list. One day we need to be able to explicitly allocate an item in a given Query_arena. Thus, when parsing a definition of a stored procedure, like CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END; we actually need to reset THD::mem_root, THD::free_list and THD::lex to parse the nested procedure statement (SELECT *). The actual reset and restore is implemented in semantic actions attached to sp_proc_stmt grammar rule. The problem is that in case of a parsing error inside a nested statement Bison generated parser would abort immediately, without executing the restore part of the semantic action. This would leave THD in an in-the-middle-of-parsing state. This is why we couldn't have had a single place where we clean up the LEX after MYSQLparse - in case of an error we needed to do a clean up immediately, in case of success a clean up could have been delayed. This left the door open for a memory leak. One of the following possibilities were considered when working on a fix: - patch the replication logic to do the clean up. Rejected as breaks module borders, replication code should not need to know the gory details of clean up procedure after CREATE TRIGGER. - wrap MYSQLparse with a function that would do a clean up. Rejected as ideally we should fix the problem when it happens, not adjust for it outside of the problematic code. - make sure MYSQLparse cleans up after itself by invoking the clean up functionality in the appropriate places before return. Implemented in this patch. - use %destructor rule for sp_proc_stmt to restore THD - cleaner than the prevoius approach, but rejected because needs a careful analysis of the side effects, and this patch is for 5.0, and long term we need to use the next alternative anyway - make sure that sp_proc_stmt doesn't juggle with THD - this is a large work that will affect many modules. Cleanup: move main_lex and main_mem_root from Statement to its only two descendants Prepared_statement and THD. This ensures that when a Statement instance was created for purposes of statement backup, we do not involve LEX constructor/destructor, which is fairly expensive. In order to track that the transformation produces equivalent functionality please check the respective constructors and destructors of Statement, Prepared_statement and THD - these members were used only there. This cleanup is unrelated to the patch.	19 years ago
tsmith@siva.hindu.god	041bea85bf	Bug #25075 : sql_class.cc doesn't compile with --without-query-cache Wrap query_cache_init_query() call with #ifdef HAVE_QUERY_CACHE in THD::THD()	19 years ago
malff/marcsql@weblab.(none)	b216d959bb	Bug#8407 (Stored functions/triggers ignore exception handler) Bug 18914 (Calling certain SPs from triggers fail) Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02') Bug 21825 (Incorrect message error deleting records in a table with a trigger for inserting) Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency error) Bug 25345 (Cursors from Functions) This fix resolves a long standing issue originally reported with bug 8407, which affect the behavior of Stored Procedures, Stored Functions and Trigger in many different ways, causing symptoms reported by all the bugs listed. In all cases, the root cause of the problem traces back to 8407 and how the server locks tables involved with sub statements. Prior to this fix, the implementation of stored routines would: - compute the transitive closure of all the tables referenced by a top level statement - open and lock all the tables involved - execute the top level statement "transitive closure of tables" means collecting: - all the tables, - all the stored functions, - all the views, - all the table triggers - all the stored procedures involved, and recursively inspect these objects definition to find more references to more objects, until the list of every object referenced does not grow any more. This mechanism is known as "pre-locking" tables before execution. The motivation for locking all the tables (possibly) used at once is to prevent dead locks. One problem with this approach is that, if the execution path the code really takes during runtime does not use a given table, and if the table is missing, the server would not execute the statement. This in particular has a major impact on triggers, since a missing table referenced by an update/delete trigger would prevent an insert trigger to run. Another problem is that stored routines might define SQL exception handlers to deal with missing tables, but the server implementation would never give user code a chance to execute this logic, since the routine is never executed when a missing table cause the pre-locking code to fail. With this fix, the internal implementation of the pre-locking code has been relaxed of some constraints, so that failure to open a table does not necessarily prevent execution of a stored routine. In particular, the pre-locking mechanism is now behaving as follows: 1) the first step, to compute the transitive closure of all the tables possibly referenced by a statement, is unchanged. 2) the next step, which is to open all the tables involved, only attempts to open the tables added by the pre-locking code, but silently fails without reporting any error or invoking any exception handler is the table is not present. This is achieved by trapping internal errors with Prelock_error_handler 3) the locking step only locks tables that were successfully opened. 4) when executing sub statements, the list of tables used by each statements is evaluated as before. The tables needed by the sub statement are expected to be already opened and locked. Statement referencing tables that were not opened in step 2) will fail to find the table in the open list, and only at this point will execution of the user code fail. 5) when a runtime exception is raised at 4), the instruction continuation destination (the next instruction to execute in case of SQL continue handlers) is evaluated. This is achieved with sp_instr::exec_open_and_lock_tables() 6) if a user exception handler is present in the stored routine, that handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be trapped by stored routines. If no handler exists, then the runtime execution will fail as expected. With all these changes, a side effect is that view security is impacted, in two different ways. First, a view defined as "select stored_function()", where the stored function references a table that may not exist, is considered valid. The rationale is that, because the stored function might trap exceptions during execution and still return a valid result, there is no way to decide when the view is created if a missing table really cause the view to be invalid. Secondly, testing for existence of tables is now done later during execution. View security, which consist of trapping errors and return a generic ER_VIEW_INVALID (to prevent disclosing information) was only implemented at very specific phases covering opening tables, but not covering the runtime execution. Because of this existing limitation, errors that were previously trapped and converted into ER_VIEW_INVALID are not trapped, causing table names to be reported to the user. This change is exposing an existing problem, which is independent and will be resolved separately.	19 years ago
antony@ppcg5.local	dc24473cb2	WL#2936 "Server Variables for Plugins" Implement support for plugins to declare server variables. Demonstrate functionality by removing InnoDB specific code from sql/* New feature for HASH - HASH_UNIQUE flag New feature for DYNAMIC_ARRAY - initializer accepts preallocated ptr. Completed support for plugin reference counting.	19 years ago
bar@mysql.com	dd0c43d5fa	Bug#15126 character_set_database is not replicated (LOAD DATA INFILE need it) This patch fixes problem that LOAD DATA could use different character sets when loading files on master and on slave sides: - Adding replication of thd->variables.collation_database - Adding optional character set clause into LOAD DATA Note, the second way, with explicit CHARACTER SET clause should be the recommended way to load data using an alternative character set. The old way, using "SET @@character_set_database=xxx" should be gradually depricated.	19 years ago
cbell/Chuck@mysql_cab_desk.	d7e4de9937	BUG#20141 "User-defined variables are not replicated properly for SF/Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.	19 years ago
monty@mysql.com/narttu.mysql.fi	520d1b4144	Fixed compilations problems and warnings on windows	19 years ago
cbell/Chuck@mysql_cab_desk.	4c6ced9fc5	BUG#20141 "User-defined variables are not replicated properly for SF/ Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.	19 years ago
monty@mysql.com/narttu.mysql.fi	f0ae3ce9b9	Fixed compiler warnings Fixed compile-pentium64 scripts Fixed wrong estimate of update_with_key_prefix in sql-bench Merge bk-internal.mysql.com:/home/bk/mysql-5.1 into mysql.com:/home/my/mysql-5.1 Fixed unsafe define of uint4korr() Fixed that --extern works with mysql-test-run.pl Small trivial cleanups This also fixes a bug in counting number of rows that are updated when we have many simultanous queries Move all connection handling and command exectuion main loop from sql_parse.cc to sql_connection.cc Split handle_one_connection() into reusable sub functions. Split create_new_thread() into reusable sub functions. Added thread_scheduler; Preliminary interface code for future thread_handling code. Use 'my_thread_id' for internal thread id's Make thr_alarm_kill() to depend on thread_id instead of thread Make thr_abort_locks_for_thread() depend on thread_id instead of thread In store_globals(), set my_thread_var->id to be thd->thread_id. Use my_thread_var->id as basis for my_thread_name() The above changes makes the connection we have between THD and threads more soft. Added a lot of DBUG_PRINT() and DBUG_ASSERT() functions Fixed compiler warnings Fixed core dumps when running with --debug Removed setting of signal masks (was never used) Made event code call pthread_exit() (portability fix) Fixed that event code doesn't call DBUG_xxx functions before my_thread_init() is called. Made handling of thread_id and thd->variables.pseudo_thread_id uniform. Removed one common 'not freed memory' warning from mysqltest Fixed a couple of usage of not initialized warnings (unlikely cases) Suppress compiler warnings from bdb and (for the moment) warnings from ndb	19 years ago
cmiller@zippy.cornsilk.net	6e096ee8d9	Prevent bugs by making DBUG_* expressions syntactically equivalent to a single statement. --- Bug#24795: SHOW PROFILE Profiling is only partially functional on some architectures. Where there is no getrusage() system call, presently Null values are returned where it would be required. Notably, Windows needs some love applied to make it as useful. Syntax this adds: SHOW PROFILES SHOW PROFILE [types] [FOR QUERY n] [OFFSET n] [LIMIT n] where "n" is an integer and "types" is zero or many (comma-separated) of "CPU" "MEMORY" (not presently supported) "BLOCK IO" "CONTEXT SWITCHES" "PAGE FAULTS" "IPC" "SWAPS" "SOURCE" "ALL" It also adds a session variable (boolean) "profiling", set to "no" by default, and (integer) profiling_history_size, set to 15 by default. This patch abstracts setting THDs' "proc_info" behind a macro that can be used as a hook into the profiling code when profiling support is compiled in. All future code in this line should use that mechanism for setting thd->proc_info. --- Tests are now set to omit the statistics. --- Adds an Information_schema table, "profiling" for access to "show profile" data. --- Merge zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community-3--bug24795 into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-community --- Fix merge problems. --- Fixed one bug in the query_source being NULL. Updated test results. --- Include more thorough profiling tests. Improve support for prepared statements. Use session-specific query IDs, starting at zero. --- Selecting from I_S.profiling is no longer quashed in profiling, as requested by Giuseppe. Limit the size of captured query text. No longer log queries that are zero length.	19 years ago
thek@kpdesk.mysql.com	19dfc42eb6	Bug#23240 --init_file statements with NOW() reports '1970-01-01 11:00:00'as the date time - Starting time of a query sent by bootstrapping wasn't initialized and starting time defaulted to 0. This later used value by NOW- item and was translated to 1970-01-01 11:00:00. - Marketing the time with thd->set_time() before the call to mysql_parse resolves this issue. - set_time was refactored to be part of the thd->init_for_queries- process.	19 years ago
msvensson@pilot.mysql.com	45fe5879f4	Bug#18628 mysql-test-run: security problem(part1) - Implement --secure-file-priv=<dir> option that limits "load_file", "LOAD DATA" and "SELECT .. INTO OUTFILE" to work with files in specified dir. - Use above option for mysqld in mysql-test-run.pl	19 years ago
mats@romeo.(none)	e61a1841a5	BUG#22583 (RBR between MyISAM and non-MyISAM tables containing BIT field does not work): Changing packed row format to only include null bits for those columns that are present in the row as well as writing BIT columns in a storage engine-independent format. The change in row format is incompatible with the previous format and a slave will not be able to read the new events.	19 years ago
guilhem@gbichot3.local	be389f62de	Mechanical class renaming: Protocol_simple->Protocol_text; Protocol_prep->Protocol_binary and also THD::protocol_simple->THD::protocol_text, THD::protocol_prep->THD::protocol_binary. Reason: the binary protocol is not bound to be used only with prepared statements long term (see WL#3559 "Decouple binary protocol from prepared statements"). Renaming now is pressing because the fix for BUG#735 "Prepared Statements: there is no support for Query Cache" will introduce a new member in class Query_cache_flags telling about the protocol's nature. Other reason: "simple" is less accurate than "text". Future patches for BUG#735 will rely on this cset.	19 years ago
monty@mysql.com/narttu.mysql.fi	410fc81a72	After merge fixes Removed a lot of compiler warnings Removed not used variables, functions and labels Initialize some variables that could be used unitialized (fatal bugs) %ll -> %l	19 years ago
cmiller@zippy.cornsilk.net	10cdf90bd3	Bug#24795: Add SHOW PROFILE Patch contributed by Jeremy Cole. CLA received Oct 2006 by Kaj Arnö Add rudimentary query profiling support.	19 years ago
mskold/marty@mysql.com/linux.site	8272333243	ndb_use_transactions is set from value for command line flag	19 years ago
kent@mysql.com/kent-amd64.(none)	6523aca729	my_strtoll10-x86.s: Corrected spelling in copyright text Makefile.am: Don't update the files from BitKeeper Many files: Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header Adjusted year(s) in copyright header Many files: Added GPL copyright text Removed files: Docs/Support/colspec-fix.pl Docs/Support/docbook-fixup.pl Docs/Support/docbook-prefix.pl Docs/Support/docbook-split Docs/Support/make-docbook Docs/Support/make-makefile Docs/Support/test-make-manual Docs/Support/test-make-manual-de Docs/Support/xwf	19 years ago
kent@mysql.com/kent-amd64.(none)	226a5c833f	Many files: Changed header to GPL version 2 only	19 years ago
monty@mysql.com/narttu.mysql.fi	88dd873de0	Fixed compiler warnings detected by option -Wshadow and -Wunused: - Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes	19 years ago
cbell/Chuck@suse.vabb.com	9f36c1c286	WL#3618 - Remove HAVE_ROW_BASED_REPLICATION from source code. Please see worklog for details on files changed.	19 years ago
iggy@rolltop.ignatz42.dyndns.org	71970547da	Bug#20836 Selecting into variables results in wrong results being returned - Comment Cleanup.	19 years ago
kostja@bodhi.local	87a87bc04b	A fix and a test case for Bug#24179 "select b into $var" fails with --cursor_protocol": fix a misleading error message in case of SELECT .. INTO.	19 years ago
iggy@rolltop.ignatz42.dyndns.org	3add79dd11	Bug#20836 Selecting into variables results in wrong results being returned - Post-merge cleanup. - Disabled this bug's test for 5.x until 16861 is resolved.	19 years ago
iggy@rolltop.ignatz42.dyndns.org	761a88ee0d	Bug#20836 Selecting into variables results in wrong results being returned This error is displayed anytime the SELECT statement needs a temp table to return correct results because the object (select_dumpvar) that represents variables named in the INTO clause stored the results before the temp table was considered. The problem was fixed by creating the necessary Item_func_set_user_var objects once the correct data is ready.	19 years ago
monty@mysql.com/nosik.monty.fi	fa81a82e7f	Fixed a LOT of compiler warnings Added missing DBUG_RETURN statements (in mysqldump.c) Added missing enums Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.	19 years ago
monty@mysql.com/nosik.monty.fi	f6682e2743	Added --debug-info to most clients to detect memory leaks in mysql-test-run Moved .progress files into the log directory Moved 'cluster' database tables into the MySQL database, to not have 'cluster' beeing a reserved database name Fixed bug where mysqld got a core dump when trying to use a table created by MySQL 3.23 Fixed some compiler warnings Fixed small memory leak in libmysql Note that this doesn't changeset doesn't include the new mysqldump.c code required to run some tests. This will be added when I merge 5.0 to 5.1	19 years ago
mats@romeo.(none)	600a6a676c	BUG#24403 (valgrind complaint on uninited st_table for innodb + rbr): Removing DBUG_DUMP printouts for valgrind builds since they trigger warnings. Removing valgrind memory checks completely. Removing bzero() of record when opening table that was added earlier.	19 years ago
monty@mysql.com/nosik.monty.fi	e825879800	Remove compiler warnings (Mostly in DBUG_PRINT() and unused arguments) Fixed bug in query cache when used with traceing (--with-debug) Fixed memory leak in mysqldump Removed warnings from mysqltest scripts (replaced -- with #)	19 years ago
mats@romeo.(none)	1cff21b531	Changeset to fix a valgrind error in the main tree. Adding class to handle temporary allocate of memory during write of rows. Eliminating cut'n-paste error between THD::binlog_{write,update,delete}_row().	19 years ago
cbell/Chuck@mysql_cab.	367a41c308	Changes to the code are necessary to compile on Windows. Typecasts are needed in several DBUG_DUMP statements. CAB 01 Nov 2006	19 years ago
mats@romeo.(none)	83f8e17258	BUG#18581 (Creation of system tables recorded in binlog causing slave failure): Not replicating the mysql database at all any more. All changes to mysql tables are replicated by replicating the statements that do the changes.	19 years ago
msvensson@shellback.(none)	e8c7f19179	Improve comments around FLUSH STATUS It's not possible to flush the global status variables in 5.0 Update test case so it works by recording the value of handle_rollback before and compare it to the value after	19 years ago
msvensson@shellback.(none)	631c82d2ea	Bug#18888 Trying to overwrite sql/lex_hash.h during build - As a sideeffect of the patch to generate lex_hash.h only once on the machine where the source dist was produced, a problem was found when compiling a mysqld without partition support - it would crash when looking up the lex symbols due to mismatch between lex.h and the generated lex_hash.h - Remove the ifdef for partition in lex.h - Fix minor problem with"EXPLAIN PARTITION" when not compiled with partition(existed also without the above patch) - Add test case that will be run when we don't have partition support compiled into mysqld - Return error ER_FEATURE_DISABLED if user tries to use PARTITION when there is no support for it.	19 years ago
andrey@example.com	102d36b7f6	Fix for bug#23379 "wrong time value in SHOW PROCESSLIST" The value taken to be shown in SHOW PROCESSLIST is not initialized when THD is created and will be random for unauthenticated connections. To the documentor: Random value, instead of NULL, was shown, in SHOW PROCESSLIST for still non-authenticated connections.	19 years ago
andrey@example.com	9010a79527	Fix for bug#23379 "wrong time value in SHOW PROCESSLIST" The value taken to be shown in SHOW PROCESSLIST is not initialized when THD is created and will be random for unauthenticated connections. To the documentor: Random value, instead of NULL, was shown, in SHOW PROCESSLIST for still non-authenticated connections.	19 years ago
kent@mysql.com/c-584072d5.010-2112-6f72651.cust.bredbandsbolaget.se	f0bb52ab13	log_event.cc, sql_class.cc: VisualStudio needs cast from (byte) to (const char), 3rd arg to _db_dump_()	19 years ago
kroki/tomash@moonlight.intranet	62c79bee51	After merge fix.	19 years ago
kroki/tomash@moonlight.intranet	8798b462b5	Fix for the patch for bug#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. Reding of LAST_INSERT_ID inside stored function wasn't noted by caller, and no LAST_INSERT_ID_EVENT was issued for binary log. The solution is to add THD::last_insert_id_used_bin_log, which is much like THD::last_insert_id_used, but is reset only for upper-level statements. This new variable is used to issue LAST_INSERT_ID_EVENT.	19 years ago
kroki/tomash@moonlight.intranet	5ea8adfae7	BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).	19 years ago
mats@romeo.(none)	f5b8614fc7	BUG#22550 (Replication of BIT column failing): Using move_field_offset() to move field pointer to other record before calling pack()/unpack().	19 years ago
guilhem@gbichot3.local	a8836b7dde	Fixing problems I identified in my auto_increment work pushed in July (as part of the auto_increment cleanup of WL#3146; let's not be sad, that monster push still removed serious bugs): one problem with INSERT DELAYED (unexpected interval releases), one with stored functions (wrong auto_inc binlogging). These bugs were not released.	19 years ago
evgen@sunlight.local	f17a536e09	Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Sorting by RAND() uses a temporary table in order to get a correct results. User defined variable was set during filling the temporary table and later on it is substituted for its value from the temporary table. Due to this it contains the last value stored in the temporary table. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value.	20 years ago
kroki/tomash@moonlight.intranet	0f0ddc398a	BUG#21051: RESET QUERY CACHE very slow when query_cache_type=0 There were two problems: RESET QUERY CACHE took a long time to complete and other threads were blocked during this time. The patch does three things: 1 fixes a bug with improper use of test-lock-test_again technique. AKA Double-Checked Locking is applicable here only in few places. 2 Somewhat improves performance of RESET QUERY CACHE. Do my_hash_reset() instead of deleting elements one by one. Note however that the slowdown also happens when inserting into sorted list of free blocks, should be rewritten using balanced tree. 3 Makes RESET QUERY CACHE non-blocking. The patch adjusts the locking protocol of the query cache in the following way: it introduces a flag flush_in_progress, which is set when Query_cache::flush_cache() is in progress. This call sets the flag on enter, and then releases the lock. Every other call is able to acquire the lock, but does nothing if flush_in_progress is set (as if the query cache is disabled). The only exception is the concurrent calls to Query_cache::flush_cache(), that are blocked until the flush is over. When leaving Query_cache::flush_cache(), the lock is acquired and the flag is reset, and one thread waiting on Query_cache::flush_cache() (if any) is notified that it may proceed.	20 years ago
mats@romeo.(none)	691355b6a3	BUG#20863 (if binlog format is changed between update and unlock table, wrong binlogging): Fix to allow the binlog format to be changed between the LOCK and UNLOCK tables, as well as under MIXED mode.	20 years ago
evgen@sunlight.local	799ecc9f2a	After merge fix	20 years ago

... 2 3 4 5 6 ...

1073 Commits (94098b22c04d94138b71398172a819308bca0338)