- 14 May, 2007 4 commits
-
-
anozdrin/alik@ibm. authored
-
anozdrin/alik@ibm. authored
-
anozdrin/alik@ibm. authored
-
kostja@vajra.(none) authored
-
- 11 May, 2007 4 commits
-
-
dlenev@mockturtle.local authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-cts-3
-
dlenev@mockturtle.local authored
Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT with locked tables" Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers" Bug #24738 "CREATE TABLE ... SELECT is not isolated properly" Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when temporary table exists" Deadlock occured when one tried to execute CREATE TABLE IF NOT EXISTS ... SELECT statement under LOCK TABLES which held read lock on target table. Attempt to execute the same statement for already existing target table with triggers caused server crashes. Also concurrent execution of CREATE TABLE ... SELECT statement and other statements involving target table suffered from various races (some of which might've led to deadlocks). Finally, attempt to execute CREATE TABLE ... SELECT in case when a temporary table with same name was already present led to the insertion of data into this temporary table and creation of empty non-temporary table. All above problems stemmed from the old implementation of CREATE TABLE ... SELECT in which we created, opened and locked target table without any special protection in a separate step and not with the rest of tables used by this statement. This underminded deadlock-avoidance approach used in server and created window for races. It also excluded target table from prelocking causing problems with trigger execution. The patch solves these problems by implementing new approach to handling of CREATE TABLE ... SELECT for base tables. We try to open and lock table to be created at the same time as the rest of tables used by this statement. If such table does not exist at this moment we create and place in the table cache special placeholder for it which prevents its creation or any other usage by other threads. We still use old approach for creation of temporary tables. Also note that we decided to postpone introduction of some tests for concurrent behaviour of CREATE TABLE ... SELECT till 5.1. The main reason for this is absence in 5.0 ability to set @@debug variable at runtime, which can be circumvented only by using several test files with individual .opt files. Since the latter is likely to slowdown test-suite unnecessary we chose not to push this tests into 5.0, but run them manually for this version and later push their optimized version into 5.1
-
kostja@vajra.(none) authored
by moving yet another relevant flag to it from struct LEX.
-
- 10 May, 2007 4 commits
-
-
kostja@vajra.(none) authored
-
kostja@vajra.(none) authored
into vajra.(none):/opt/local/work/mysql-5.0-21483
-
thek@adventure.(none) authored
-
kostja@vajra.(none) authored
of requested lock type and requested table operation from mysql_insert into a separate function.
-
- 08 May, 2007 4 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/bug27792/my50-bug27792
-
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.
-
- 07 May, 2007 2 commits
-
-
thek@adventure.(none) authored
into adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime
-
thek@adventure.(none) authored
- In some cases, flow control optimization implemented in sp::optimize removes hreturn instructions, causing SQL exception handlers to: * never return * execute wrong logic - This patch overrides default short cut optimization on hreturn instructions to avoid this problem.
-
- 02 May, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
into weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge
-
joerg@trift2. authored
-
- 01 May, 2007 2 commits
-
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/50
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/50
-
- 30 Apr, 2007 9 commits
-
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/mysql50
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/50
-
tsmith@quadxeon.mysql.com authored
tmpdir has uppercase Fix: don't convert mysql_tmpdir to lower case when building the path to a temporary table
-
dkatz@damien-katzs-computer.local authored
into damien-katzs-computer.local:/Users/dkatz/50_frm_files
-
tnurnberg@maint1.mysql.com authored
into maint1.mysql.com:/data/localhome/tnurnberg/50-27293
-
mysqldump didn't properly handle getting no data on SHOW CREATE PROCEDURE. If S/C/P fails (due to dumping user's insufficient privileges on mysql.proc, say), mysqldump will print a comment to that effect to the output and return an error-code. If the -f (force) option is used, the dump will continue, otherwise, it will abort right there and then. Also fixes Bug#22761, "mysqldump reports no errors when using --routines without mysql.proc privileges" --- Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint into mysql.com:/home/tnurnberg/27293/50-27293
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug24856
-
igor@olga.mysql.com authored
-
- 29 Apr, 2007 9 commits
-
-
igor@olga.mysql.com authored
some rollup rows (rows with NULLs for grouping attributes) if GROUP BY list contained constant expressions. This happened because the results of constant expressions were not put in the temporary table used for duplicate elimination. In fact a constant item from the GROUP BY list of a ROLLUP query can be replaced for an Item_null_result object when a rollup row is produced . Now the JOIN::rollup_init function wraps any constant item referenced in the GROYP BY list of a ROLLUP query into an Item_func object of a special class that is never detected as constant item. This ensures creation of fields for such constant items in temporary tables and guarantees right results when the result of the rollup operation first has to be written into a temporary table, e.g. in the cases when duplicate elimination is required.
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/16377-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
The test case for the bug#27590 is altered.
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
kaa@polly.local authored
If isinf() is not available on a target platform, use our own imlementation via finite() and isnan(). If either of the last two is not available as well, use simple replacements which are platform-neutral, but slower than compiler intrinsics.
-
gshchepa/uchum@gshchepa.loc authored
-
gshchepa/uchum@gshchepa.loc authored
into gshchepa.loc:/home/uchum/work/bk-trees/mysql-5.0-opt-13191
-