- 26 Jan, 2005 1 commit
-
-
marko@hundin.mysql.fi authored
into hundin.mysql.fi:/home/marko/k/mysql-4.0
-
- 25 Jan, 2005 3 commits
-
-
igor@rurik.mysql.com authored
Added a test case for bug #7672. sql_yacc.yy: Fixed bug #7672. Made queries of the form (SELECT ...) ORDER BY ... to be equivalent to SELECT ... ORDER BY ...
-
marko@hundin.mysql.fi authored
-
marko@hundin.mysql.fi authored
-
- 22 Jan, 2005 1 commit
-
-
igor@rurik.mysql.com authored
Added a test case for bug #7945. sql_select.cc: Fixed bug #7945. If DISTINCT is used only with constants in a query with GROUP BY, we can apply an optimization that set LIMIT to 1 only in the case when there is no SQL_CALC_FOUND_ROWS.
-
- 20 Jan, 2005 1 commit
-
-
lenz@mysql.com authored
environment (using "build" on SUSE Linux)
-
- 18 Jan, 2005 6 commits
-
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-4.0-clean
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-4.0-bg7884
-
dlenev@mysql.com authored
macros. It does not fixes any bugs in 4.0. But it prevents from future error in any bugfixes that may use these macros. Also after merging into 4.1 tree this cleanup will fix bug #7884 "Able to add invalid unique index on TIMESTAMP prefix".
-
lenz@mysql.com authored
into mysql.com:/space/my/mysql-4.0
-
jimw@mysql.com authored
set to a negative value. (Bug #7700)
-
monty@mysql.com authored
-
- 17 Jan, 2005 1 commit
-
-
lenz@mysql.com authored
Mac OS X PKGs with Do-pkg
-
- 15 Jan, 2005 1 commit
-
-
monty@mysql.com authored
-
- 14 Jan, 2005 1 commit
-
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-4.0-clean
-
- 13 Jan, 2005 3 commits
-
-
jimw@mysql.com authored
it has been specified. (Bug #7347)
-
heikki@hundin.mysql.fi authored
Fix a theoretical hang over the adaptive hash latch in InnoDB if one runs INSERT ... SELECT ... (binlog not enabled), or a multi-table UPDATE or DELETE, and only the read tables are InnoDB type, the rest are MyISAM; this also fixes bug #7879 for InnoDB type tables
-
marko@hundin.mysql.fi authored
into hundin.mysql.fi:/home/marko/k/mysql-4.0
-
- 12 Jan, 2005 6 commits
-
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.0
-
serg@serg.mylan authored
reported by Javier Fernandez-Sanguino Pena and Debian Security Audit Team (http://www.debian.org/security/audit)
-
konstantin@mysql.com authored
case will be added to client_test in 4.1
-
marko@hundin.mysql.fi authored
open interface for setting the "delete-on-close" flag.
-
serg@serg.mylan authored
into serg.mylan:/usr/home/serg/Abk/mysql-4.0
-
serg@serg.mylan authored
-
- 10 Jan, 2005 1 commit
-
-
guilhem@mysql.com authored
mysql_admin_table() attempted to write to a vio which was 0. I could have fixed mysql_admin_table() but fixing my_net_write() looked more future-proof.
-
- 07 Jan, 2005 1 commit
-
-
mwagner@here.mwagner.org authored
Made the default --mail address to be <build@mysql.com>.
-
- 06 Jan, 2005 2 commits
-
-
guilhem@mysql.com authored
This happened only if my_write() couldn't write even one byte. I cannot easily add a .test for this, but I tested by hand before and after the change.
-
lenz@mysql.com authored
build (to make the test suite pass)
-
- 05 Jan, 2005 1 commit
-
-
jimw@mysql.com authored
official binary builds for Linux that are built against a static glibc with a 128k thread stack size limit can be compiled with a default that doesn't result in a harmless (but oft-misunderstood) warning message. (Bug #6226)
-
- 04 Jan, 2005 1 commit
-
-
jimw@mysql.com authored
-
- 03 Jan, 2005 1 commit
-
-
lenz@mysql.com authored
ChangeLog, too (to be more exact when tagging a release that's based on a merge ChangeSet)
-
- 31 Dec, 2004 2 commits
-
-
serg@sergbook.mysql.com authored
into sergbook.mysql.com:/usr/home/serg/Abk/mysql-4.0
-
lenz@mysql.com authored
-
- 30 Dec, 2004 3 commits
-
-
serg@sergbook.mysql.com authored
-
dlenev@mysql.com authored
into mysql.com:/home/dlenev/src/mysql-4.0-bg7297
-
dlenev@mysql.com authored
the Epoch". (With after review fixes).
-
- 27 Dec, 2004 2 commits
-
-
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
-
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
-
- 24 Dec, 2004 1 commit
-
-
ram@gw.mysql.r18.ru authored
-
- 23 Dec, 2004 1 commit
-
-
Sinisa@sinisa.nasamreza.org authored
into sinisa.nasamreza.org:/mnt/work/mysql-4.0
-