- 28 Dec, 2004 1 commit
-
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-4.1
-
- 27 Dec, 2004 19 commits
-
-
heikki@hundin.mysql.fi authored
Manually merge the latest FOREIGN KEY lock wait + DROP TABLE fix from 4.0
-
heikki@hundin.mysql.fi authored
into hundin.mysql.fi:/home/heikki/mysql-4.1
-
lars@mysql.com authored
into mysql.com:/home/bkroot/mysql-4.1
-
heikki@hundin.mysql.fi authored
-
lars@mysql.com authored
- Added a hash to keep track of database-table pairs. - Specified database-table tables do not get dumped
-
heikki@hundin.mysql.fi authored
Fix the previous bug fix: dropping a table with FOREIGN KEY checks running on it caused a cascade of failed drops while the foreign key check was waiting for a lock
-
lenz@mysql.com authored
non-numerical characters (if $VERSION was e.g. "4.1.8a", $MYSQL_VERSION_ID resulted in "40108a", which broke the build as MYSQL_VERSION_ID must be numerical)
-
heikki@hundin.mysql.fi authored
Merge the two FOREIGN KEY bug fixes from 4.0, and add a TODO comment
-
heikki@hundin.mysql.fi authored
into hundin.mysql.fi:/home/heikki/mysql-4.1
-
heikki@hundin.mysql.fi authored
Fix bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table(), since that operation assumes no waiting locks on the table or its records row0mysql.c: Fix bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a foreign key constraint
-
timour@mysql.com authored
into mysql.com:/home/timka/mysql/src/4.1-dbg
-
timour@mysql.com authored
Fix for BUG#7377. This fix adds the same implementation for ha_myisammgr::index_type as in version 5.0.
-
ram@gw.mysql.r18.ru authored
-
heikki@hundin.mysql.fi authored
Return a sensible error code from DISCARD TABLESPACE, if it fails because the table is referenced by a FOREIGN KEY
-
heikki@hundin.mysql.fi authored
Return a sensible error code from DISCARD TABLESPACE, if it fails because the table is referenced by a FOREIGN KEY
-
heikki@hundin.mysql.fi authored
Fix typo
-
heikki@hundin.mysql.fi authored
Correct typo
-
heikki@hundin.mysql.fi authored
into hundin.mysql.fi:/home/heikki/mysql-4.1
-
heikki@hundin.mysql.fi authored
Fix InnoDB critical bug #7496; we scan the InnoDB data dictionary also at a normal mysqld startup, and create the spaces, so that we know the mapping space id -> .ibd file name; fix an infinite loop if DISCARD TABLESPACE coincides with INSERT or some other table operation; fix a potential crash if DISCARD TABLESPACE coincides with a cascaded FOREIGN KEY operation in the same table; do not allow DISCARD TABLESPACE of a referenced table if FOREIGN_KEY_CHECKS=1
-
- 26 Dec, 2004 3 commits
-
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-4.1-0
-
igor@rurik.mysql.com authored
Added a couple of new test cases for bug #7351.
-
igor@rurik.mysql.com authored
Added test cases for bug #7351. item_cmpfunc.cc: Fixed bug #7351: incorrect result for a query with a subquery returning empty set. If in the predicate v IN (SELECT a FROM t WHERE cond) v is null, then the result of the predicate is either INKNOWN or FALSE. It is FALSE if the subquery returns an empty set. item_subselect.cc: Fixed bug #7351: incorrect result for a query with a subquery returning empty set. The problem was due to not a quite legal transformation for 'IN' subqueries. A subquery containing a predicate of the form v IN (SELECT a FROM t WHERE cond) was transformed into EXISTS(SELECT a FROM t WHERE cond AND (a=v OR a IS NULL)). Yet, this transformation is valid only if v is not null. If v is null, then, in the case when (SELECT a FROM t WHERE cond) returns an empty set the value of the predicate is FALSE, otherwise the result of the predicate is INKNOWN. The fix resolves this problem by changing the result of the transformation to EXISTS(SELECT a FROM t WHERE cond AND (v IS NULL OR (a=v OR a IS NULL))) in the case when v is nullable. The new transformation prevents applying the lookup optimization for IN subqueries. To make it still applicable we have to introduce guarded access methods.
-
- 24 Dec, 2004 5 commits
-
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.1
-
serg@serg.mylan authored
-
Sinisa@sinisa.nasamreza.org authored
-
Sinisa@sinisa.nasamreza.org authored
-
ram@gw.mysql.r18.ru authored
-
- 23 Dec, 2004 10 commits
-
-
dlenev@mysql.com authored
user limits to behave well on 5.0 tables, into 4.1 tree.
-
Sinisa@sinisa.nasamreza.org authored
into sinisa.nasamreza.org:/mnt/work/mysql-4.0
-
Sinisa@sinisa.nasamreza.org authored
-
dlenev@mysql.com authored
to behave well on 5.0 tables (well now you can't use tables from 4.1 and 5.0 with 4.0 because former use utf8, but still it is nice to have similar code in acl_init() and replace_user_table()). This also will make such GRANTs working in 5.0 (they are broken now).
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.1
-
serg@serg.mylan authored
-
wax@mysql.com authored
into mysql.com:/home/wax/mysql/mysql-4.1smemory
-
wax@kishkin.ru authored
add space after comma add space after equal add comments in vio_close_shared_memory()
-
bar@mysql.com authored
from the install directory.
-
wax@mysql.com authored
into mysql.com:/home/wax/mysql/mysql-4.1smemory
-
- 22 Dec, 2004 2 commits
-
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.1
-
serg@serg.mylan authored
don't checkin for Administrator or mysqldev sql/log.cc@1.157 restored a bugfix that was lost in a merge
-