An error occurred fetching the project authors.
- 10 Sep, 2009 1 commit
-
-
Marc Alff authored
WL#2265 (RESIGNAL) Manual merge of SIGNAL and RESIGNAL to mysql-trunk-signal, plus required dependencies.
-
- 13 Jan, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that the query cache stores packets containing the server status of the time when the cached statement was run. This might lead to a wrong transaction status in the client side if a statement is cached during a transaction and is later served outside a transaction context (and vice-versa). The solution is to take into account the transaction status when storing in and serving from the query cache.
-
- 28 Nov, 2008 1 commit
-
-
Matthias Leich authored
- disable the test suffering from Bug#41098 Query Cache returns wrong result with concurrent insert - additional improvements Details: - Move the test for the historic bug Bug 28249 Query Cache returns wrong result with concurrent insert / certain lock into its own testscript query_cache_28249.test. - query_cache.test: - replace error numbers with error names - remove trailing spaces, replace tabs with spaces - reset of @@global.log_bin_trust_function_creators to its original value at the end of the test - query_cache_28249.test: - replace sleep 5 with poll routine - avoid random differences caused by concurrent_inserts effects - improved comments and formatting
-
- 17 Jul, 2008 1 commit
-
-
Kristofer Pettersson authored
-
- 16 Jul, 2008 1 commit
-
-
Marc Alff authored
Reverting the previous patch
-
- 10 Jul, 2008 1 commit
-
-
Sven Sandberg authored
Problem 1: tests often fail in pushbuild with a timeout when waiting for the slave to start/stop/receive error. Fix 1: Updated the wait_for_slave_* macros in the following way: - The timeout is increased by a factor ten - Refactored the macros so that wait_for_slave_param does the work for the other macros. Problem 2: Tests are often incorrectly written, lacking a source include/wait_for_slave_to_[start|stop].inc. Fix 2: Improved the chance to get it right by adding include/start_slave.inc and include/stop_slave.inc, and updated tests to use these. Problem 3: The the built-in test language command wait_for_slave_to_stop is a misnomer (does not wait for the slave io thread) and does not give as much debug info in case of failure as the otherwise equivalent macro source include/wait_for_slave_sql_to_stop.inc Fix 3: Replaced all calls to the built-in command by a call to the macro. Problem 4: Some, but not all, of the wait_for_slave_* macros had an implicit connection slave. This made some tests confusing to read, and made it more difficult to use the macro in circular replication scenarios, where the connection named master needs to wait. Fix 4: Removed the implicit connection slave from all wait_for_slave_* macros, and updated tests to use an explicit connection slave where necessary. Problem 5: The macros wait_slave_status.inc and wait_show_pattern.inc were unused. Moreover, using them is difficult and error-prone. Fix 5: remove these macros. Problem 6: log_bin_trust_function_creators_basic failed when running tests because it assumed @@global.log_bin_trust_function_creators=1, and some tests modified this variable without resetting it to its original value. Fix 6: All tests that use this variable have been updated so that they reset the value at end of test.
-
- 19 Jun, 2008 1 commit
-
-
Kristofer Pettersson authored
This bugs clarifies a warning message issued when the query cache data size becomes smaller than the minium allowed size.
-
- 13 Mar, 2008 1 commit
-
-
istruewing@stella.local authored
When concurrent inserts were disabled, statements after an INSERT were not put into the query cache. This happened because we do not save the current data file length at statement start when concurrent inserts are disabled. But we checked the always zero local length against the real file length anyway. Fixed by doing the check only if concurrent inserts are not diabled.
-
- 06 Mar, 2008 1 commit
-
-
thek@adventure.(none) authored
The initial value of free memory blocks in 0. When the query cache is enabled a new memory block gets allocated and is assigned number 1. The free memory block is later split each time query cache memory is allocated for new blocks. This means that the free memory block counter won't be reduced to zero when the number of allocated blocks are zero, but rather one. To avoid confusion this patch changes this behavior so that the free memory block counter is reset to zero when the query cache is disabled. Note that when the query cache is enabled and resized the free memory block counter was still calculated correctly.
-
- 07 Jan, 2008 1 commit
-
-
thek@adventure.(none) authored
-
- 03 Jan, 2008 1 commit
-
-
thek@adventure.(none) authored
Reseting the query cache by issuing a SET GLOBAL query_cache_size=0 caused the server to crash if a the server concurrently was saving a new result set to the query cache. The reason for this was that the invalidation wasn't waiting on the result writers to release the block level locks on the query cache.
-
- 12 Dec, 2007 1 commit
-
-
msvensson@pilot.mysql.com authored
- dynamic configuration support - safe process - cleanups - create new suite for fedarated
-
- 23 Oct, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
-
- 19 Oct, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
The uncacheable flag should be set at fix_fields() stage. Fixed by moving the flag setting to match the one in 5.1
-
- 16 Oct, 2007 2 commits
-
-
thek@adventure.(none) authored
test programs.
-
thek@adventure.(none) authored
The embedded version of the server doesn't use column level grants, and the compile directive NO_EMBEDDED_ACCESS_CHECKS should be checked instead of the redundant HAVE_QUERY_CACHE (which is always the case) to determine if column level grants should be compiled or not.
-
- 10 Sep, 2007 1 commit
-
-
malff@lambda.weblab authored
UPGRADE) Bug 17565 (RENAME DATABASE destroys events) Bug#28360 (RENAME DATABASE destroys routines) Removed the RENAME DATABASE db1 TO db2 statement. Implemented the ALTER DATABASE db UPGRADE DATA DIRECTORY NAME statement, which has the same function.
-
- 21 Aug, 2007 1 commit
-
-
thek@adventure.(none) authored
Although the query cache doesn't support retrieval of statements containing column level access control, it was still possible to cache such statements thus wasting memory. This patch extends the access control check on the target tables to avoid caching a statement with column level restrictions. Views are excepted and can be cached but only retrieved by super user account.
-
- 17 Aug, 2007 1 commit
-
-
thek@adventure.(none) authored
Although the query cache doesn't support retrieval of statements containing column level access control, it was still possible to cache such statements thus wasting memory. This patch extends the access control check on the target tables to avoid caching a statement with column level restrictions.
-
- 28 Jul, 2007 1 commit
-
-
evgen@moonbone.local authored
The subst_spvars function is used to create query string with SP variables substituted with their values. This string is used later for the binary log and for the query cache. The problem is that the query_cache_send_result_to_client function requires some additional space after the query to store database name and query cache flags. This space wasn't reserved by the subst_spvars function which led to a memory corruption and crash. Now the subst_spvars function reserves additional space for the query cache.
-
- 16 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 12 Jul, 2007 1 commit
-
-
thek@adventure.(none) authored
A race condition in the integration between MyISAM and the query cache code caused the query cache to fail to invalidate itself on concurrently inserted data. This patch fix this problem by using the existing handler interface which, upon each statement cache attempt, compare the size of the table as viewed from the cache writing thread and with any snap shot of the global table state. If the two sizes are different the global table size is unknown and the current statement can't be cached.
-
- 19 Jun, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 18 Jun, 2007 2 commits
-
-
dkatz@damien-katzs-computer.local authored
Changed code to enforce that SQL_CACHE only in the first SELECT is used to turn on caching(as documented), but any SQL_NO_CACHE will turn off caching (not documented, but a useful behaviour, especially for machine generated queries). Added test cases to explicitly test the documented caching behaviour and test cases for the reported bug.
-
thek@adventure.(none) authored
When all table blocks were removed from the query cache the client session hung in a tight loop waiting on an impossible condition while consuming a lot of CPU. This patch also corrects an error which caused valid tables to sometimes be removed from the query cache.
-
- 13 Jun, 2007 1 commit
-
-
dkatz@damien-katzs-computer.local authored
Removed the ability to cache queries containing "UUID()".
-
- 08 May, 2007 3 commits
-
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
- Queries in the query cache are identified by the individual characters in the query statement, the current database and the current environment expressed as a set of system variable flags. - Since the set of environment flags didn't properly describe the current environment unexpected results were returned from the query cache. - Query cache is now cleared when the variable ft_boolean_syntax is updated. - An identification flag for the variable default_week_format is added to the query cache record. Thanks to Martin Friebe who has supplied significant parts of this patch.
-
- 26 Apr, 2007 1 commit
-
-
evgen@moonbone.local authored
The BETWEEN function was comparing DATE/DATETIME values either as ints or as strings. Both methods have their disadvantages and may lead to a wrong result. Now BETWEEN function checks whether all of its arguments has the STRING result types and at least one of them is a DATE/DATETIME item. If so it sets up two Arg_comparator obects to compare with the compare_datetime() comparator and uses them to compare such items. Added two Arg_comparator object members and one flag to the Item_func_between class for the correct DATE/DATETIME comparison. The Item_func_between::fix_length_and_dec() function now detects whether it's used for DATE/DATETIME comparison and sets up newly added Arg_comparator objects to do this. The Item_func_between::val_int() now uses Arg_comparator objects to perform correct DATE/DATETIME comparison. The owner variable of the Arg_comparator class now can be set to NULL if the caller wants to handle NULL values by itself. Now the Item_date_add_interval::get_date() function ajusts cached_field type according to the detected type.
-
- 09 Mar, 2007 1 commit
-
-
guilhem@gbichot3.local authored
Cache". WL#1569 "Prepared Statements: implement support of Query Cache". Prepared SELECTs did not look up in the query cache, and their results were not stored in the query cache. This made them slower than non-prepared SELECTs in some cases. The fix is to re-use the expanded query (the prepared query where "?" placeholders are replaced by their values, at execution time) for searching/storing in the query cache. It works fine for statements prepared via mysql_stmt_prepare(), which are the most commonly used and were the scope of this bugfix and WL. It works less fine for statements prepared via the SQL command PREPARE...FROM, which are still not using the query cache if they have at least one parameter (because then the expanded query contains names of user variables, and user variables don't work with the query cache, even in non-prepared queries). Note that results from prepared SELECTs, which are in the binary protocol, and results from normal SELECTs, which are in the text protocol, ignore each other in the query cache, because a result in the binary protocol should never be served to a SELECT expecting the text protocol and vice-versa. Note, after this patch, bug 25843 starts applying to query cache ("changing default database between PREPARE and EXECUTE of statement breaks binlog"), we need to fix it.
-
- 14 Feb, 2007 1 commit
-
-
msvensson@pilot.mysql.com authored
- 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
-
- 17 Nov, 2006 1 commit
-
-
Fix tests for new behaviour: an error is thrown if a NON DETERMINISTIC stored function (SF) is called during statement-based replication (SBR).
-
- 14 Nov, 2006 1 commit
-
-
evgen@moonbone.local authored
The regression is caused by the fix for bug 14767. When INSERT ... SELECT used a view in the SELECT list that was not inlined, and there was an active transaction, the server could crash in Query_cache::invalidate. On INSERT ... SELECT only the table being inserted into is invalidated. Thus views that can't be inlined are skipped from invalidation. The bug manifests itself in two ways so there is 2 test cases. One checks that the only the table being inserted into is invalidated. And the second one checks that there is no crash on INSERT ... SELECT.
-
- 04 Oct, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
Update tests and result files after running with new mysqltest that better detects problems with test files
-
- 18 Sep, 2006 1 commit
-
-
gkodinov@dl145s.mysql.com authored
-
- 14 Sep, 2006 1 commit
-
-
evgen@sunlight.local authored
Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN Corrected a test case after removal of fix for bug#16377 query_cache.result, func_time.test, view.result, view.test, func_time.result: Corrected a test case after removal of fix for bug#16377 type_date.test: Added the test case for bug#21677: Wrong result when comparing a DATE and a DATETIME in BETWEEN Corrected a test case after removal of fix for bug#16377 item_cmpfunc.cc: Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377
-
- 12 Sep, 2006 1 commit
-
-
evgen@moonbone.local authored
Removed changes to the Item_func_between::fix_length_and_dec() made in the fix for bug#16377 query_cache.result: Corrected a test case after removing a fix for bug#16377
-
- 07 Sep, 2006 1 commit
-
-
evgen@moonbone.local authored
Corrected test case after removal of fix for bug#16377 type_date.test: Corrected test case after removal of fix for bug#16377 item_cmpfunc.cc: Removed changes to the agg_cmp_type() made in the for bug#16377
-
- 31 Aug, 2006 1 commit
-
-
igor@rurik.mysql.com authored
when a range condition use an invalid DATETIME constant. Now we do not use invalid DATETIME constants to form end keys for range intervals: range analysis just ignores predicates with such constants.
-