- 07 Mar, 2007 1 commit
-
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
- 02 Mar, 2007 8 commits
-
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.0
-
unknown authored
into trift2.:/MySQL/M41/manpages-4.1 support-files/mysql.spec.sh: SCCS merged
-
unknown authored
support-files/mysql.spec.sh: More man pages.
-
unknown authored
support-files/mysql.spec.sh: Another man page.
-
unknown authored
into trift2.:/MySQL/M41/manpages-4.1 support-files/mysql.spec.sh: Null-merge, the equivalent fix here is a change of its own (NDB).
-
unknown authored
support-files/mysql.spec.sh: Add the man pages for NDB.
-
unknown authored
support-files/mysql.spec.sh: Add missing man pages.
-
- 01 Mar, 2007 1 commit
-
-
unknown authored
into weblab.(none):/home/marcsql/TREE/mysql-4.1-runtime sql/sql_parse.cc: Auto merged
-
- 28 Feb, 2007 5 commits
-
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
unknown authored
EXCEPTIONS-CLIENT is now static part of repository Docs/Makefile.am: EXCEPTIONS-CLIENT is now static part of repository
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build Docs/Makefile.am: SCCS merged
-
unknown authored
EXCEPTIONS-CLIENT is now static part of repository EXCEPTIONS-CLIENT: BitKeeper file /home/kent/bk/tmp/mysql-4.0/EXCEPTIONS-CLIENT EXCEPTIONS-CLIENT: BitKeeper file /home/kent/bk/tmp/mysql-4.0/EXCEPTIONS-CLIENT Docs/Makefile.am: EXCEPTIONS-CLIENT is now static part of repository
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
- 26 Feb, 2007 1 commit
-
-
unknown authored
to the client only after the binlog write and engine commit. No testcase for this bug, as to reproduce it, we need to "kill -9" mysqld, which we cannot do in the testsuite. But, I tested by hand. sql/sql_load.cc: D in ACID means that once the client got the ok from the server, the data is durable on disk. Implies that the ok must be sent after the binlog write and after the engine commit, not before.
-
- 24 Feb, 2007 2 commits
- 22 Feb, 2007 1 commit
-
-
unknown authored
into trift2.:/MySQL/M40/mysql-4.0
-
- 20 Feb, 2007 2 commits
-
-
unknown authored
The declaration of "thr_client_alarm" had got lost, keep it in "mysys/thr_alarm.c". mysys/thr_alarm.c: After-merge fix: In 4.1, the variable "thr_client_alarm" is declared in this module.
-
unknown authored
into trift2.:/MySQL/M41/merge-4.1 include/config-win.h: Auto merged mysys/my_pthread.c: Auto merged mysys/thr_alarm.c: Auto merged mysys/my_thr_init.c: Not applicable to 4.1 in its current state. sql/mysqld.cc: Change was a backport already, null-merged to 4.1.
-
- 19 Feb, 2007 2 commits
-
-
unknown authored
into kpdesk.mysql.com:/home/thek/dev/mysql-4.1-runtime sql/sql_parse.cc: Auto merged
-
unknown authored
- Starting time of a query sent by file bootstrapping wasn't initialized and starting time defaulted to 0. This later used value by the Now- item and is translated to 1970-01-01 11:00:00. - marking the time with thd->set_time() before the call to mysql_parse resolves this issue. mysql-test/r/init_file.result: Appended test case mysql-test/std_data/init_file.dat: Appended test case mysql-test/t/init_file.test: Appended test case
-
- 16 Feb, 2007 1 commit
-
-
unknown authored
Companion change to this one ChangeSet@1.2206, 2007-01-22 02:32:07+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +8 -0 include/my_pthread.h@1.67, 2007-01-22 02:32:06+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +31 -10 which renamed "sigset()" -> "my_sigset()" but forgot to do it for Windows ... include/config-win.h: Companion change to this one ChangeSet@1.2206, 2007-01-22 02:32:07+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +8 -0 include/my_pthread.h@1.67, 2007-01-22 02:32:06+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +31 -10 which renamed "sigset()" -> "my_sigset()" but forgot to do it for Windows ...
-
- 15 Feb, 2007 1 commit
-
-
unknown authored
into trift2.:/MySQL/M41/push-4.1
-
- 13 Feb, 2007 2 commits
- 12 Feb, 2007 7 commits
-
-
unknown authored
into mysql.com:/home/hf/work/25492/my41-25492
-
unknown authored
libmysqld/lib_sql.cc: code modified to prevent freeing of memory that wasn't malloc-ed. Now we check if MYSQL_STMT::result was used.
-
unknown authored
mysys/my_pthread.c: Linkage problem with previous patch: "thr_client_alarm" must be declared in here. mysys/thr_alarm.c: Linkage problem: Declare "thr_client_alarm" over in "mysys/my_pthread.c".
-
unknown authored
Break a double declare of "uint thr_client_alarm" between "mysys/thr_alarm.c" and "mysys/my_pthread.c". mysys/my_pthread.c: Break a double declare: "uint thr_client_alarm" is also declared in "mysys/thr_alarm.c", take it from there.
-
unknown authored
mysys/my_thr_init.c: Compile error on Windows: Both "SIGALRM" and "SIGUSR1" are undefined. Fix by hiding the whole section, according to Jani it is not needed on Windows.
-
unknown authored
into mysql.com:/home/tnurnberg/24660/41-24660 sql/table.cc: Auto merged
-
unknown authored
ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales. This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from being used. Now if 0xff makes an appearance, we find a character not used in the enum and use that as a separator. If no such character exists, we throw an error. Any solution would have broken some sort of existing behaviour. This solution should serve both fractions (those with 0xff and those with ',' in their enums), but WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/ That is, mysqldump with their current server, and restore when upgrading to one with this patch. mysql-test/r/type_enum.result: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. mysql-test/t/type_enum.test: Bug#24660: "enum" field type definition problem Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable char in some locales), or ',', or both. sql/table.cc: Bug#24660: "enum" field type definition problem Revert fix for Bug#20922. sql/unireg.cc: Bug#24660: "enum" field type definition problem Use a field-separator for ENUM-values that is not part of those values. If impossible, throw error.
-
- 09 Feb, 2007 3 commits
- 08 Feb, 2007 3 commits