- 12 Jan, 2005 5 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
-
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 3 commits
-
-
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).
-
- 22 Dec, 2004 2 commits
-
-
Sinisa@sinisa.nasamreza.org authored
-
heikki@hundin.mysql.fi authored
If AUTOCOMMIT=1, do not acquire an InnoDB table lock in LOCK TABLES; this makes porting of old MyISAM applications to InnoDB easier, since in that mode InnoDB table locks caused deadlocks very easily
-
- 21 Dec, 2004 2 commits
-
-
heikki@hundin.mysql.fi authored
Put back accidentally removed undef and remove a debug def
-
heikki@hundin.mysql.fi authored
Fix InnoDB bug: on HP-UX, with a 32-bit binary, InnoDB was only able to read or write <= 2 GB files; the reason was that InnoDB treated the return value of lseek() as a 32-bit integer; lseek was used on HP-UX-11 as a replacement for pread() and pwrite() because HAVE_BROKEN_PREAD was defined on that platform
-
- 20 Dec, 2004 1 commit
-
-
mwagner@here.mwagner.org authored
Increment from 4.0.23 to 4.0.24
-
- 18 Dec, 2004 5 commits
-
-
into ltantony.rdg.cyberkinetica.homeunix.net:/usr/home/antony/work/bug7391.4
-
-
monty@mysql.com authored
-
-
Add in missing privilege checks. Tests for the privileges.
-
- 16 Dec, 2004 5 commits
-
-
joerg@mysql.com authored
into mysql.com:/M40/mysql-4.0
-
joerg@mysql.com authored
-
timour@mysql.com authored
-
timour@mysql.com authored
-
dlenev@mysql.com authored
even with zero month and day" aka "Date decoding trouble" Two digit year should be interpreted correctly as year in 20th or 21st century even with zero month and day. Only exception should be zero date '00-00-00' or '00-00-00 00:00:00'.
-
- 13 Dec, 2004 1 commit
-
-
marko@hundin.mysql.fi authored
dict_load_table(): detect the new table format of MySQL 5.0.3
-
- 11 Dec, 2004 1 commit
-
-
sergefp@mysql.com authored
into mysql.com:/dbdata/psergey/mysql-4.0-bug6976
-