- 12 Nov, 2006 1 commit
-
-
bugs/wls in cset's comments. The targetted BUG's or WL's identifier must be specified the first in the comments. The referred bugs wls can be typed in same as the targeted clickable format. If the the target of the fix is a WL and there are some references to bugs then the first found reference is regarded as "co-target" so that the bug's identifier comes up on the subject line along with the WL's and commit mail will update the bug page. The latter feature can be disarmed (if there is no need to update the referred bug's page) with typing the first a pseudo-bug pattern (bug#0). This paticular cset will generate subject line containing bug#0 (as it was the first referred) whereas the old version would put in the subject line the last referred pattern (e.g bug#2147483648).
-
- 08 Nov, 2006 3 commits
-
-
into mysql.com:/usr/home/bar/mysql-4.1.b23451v2
-
fixing a flow of the test
-
into dsl-hkibras-fe30f900-107.dhcp.inet.fi:/home/elkin/MySQL/TEAM/BARE/mysql-4.1-rpl
-
- 07 Nov, 2006 2 commits
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
Problem: GROUP_CONCAT on a multi-byte column can truncate in the middle of a multibyte character when applying group_concat_max_len limit. It produces an invalid multi-byte character in the result string. The second, easier version - reusing old "warning_for_row" flag, instead of introducing of "result_is_full" - which was added in the previous commit.
-
- 03 Nov, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 02 Nov, 2006 8 commits
-
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-4.1-maint
-
Raise version number to 4.1.23
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/mysql-4.1-maint
-
thek@kpdesk.mysql.com authored
- 'false' not defined in C, use FALSE instead.
-
into mysql.com:/usr/home/ram/work/bug22913/my41-bug22913
-
We don't check for errors that may occur during data printing.
-
- 01 Nov, 2006 4 commits
-
-
kostja@bodhi.local authored
into bodhi.local:/opt/local/work/mysql-4.1-runtime
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-4.1-maint
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-4.1-maint
-
thek@kpdesk.mysql.com authored
into kpdesk.mysql.com:/home/thek/dev/mysql-4.1-maint
-
- 31 Oct, 2006 5 commits
-
-
msvensson@shellback.(none) authored
- Only read *.pid - Only allow it to contain a number
-
msvensson@shellback.(none) authored
-
msvensson@shellback.(none) authored
-
thek@kpdesk.mysql.com authored
- Because my_seek actually is capable of returning an error code we should exploit that in the best possible way. - There might be kernel errors or other errors we can't predict and capturing the return value of all system calls gives us better understanding of possible errors.
-
into mysql.com:/usr/home/ram/work/bug23412/my41-bug23412
-
- 30 Oct, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21915
-
kroki/tomash@moonlight.intranet authored
If the user has specified --max-connections=N or --table-open-cache=M options to the server, a warning could be given that some values were recalculated, and table-open-cache could be assigned greater value. Note that both warning and increase of table-open-cache were totally harmless. This patch fixes recalculation code to ensure that table-open-cache will be never increased automatically and that a warning will be given only if some values had to be decreased due to operating system limits. No test case is provided because we neither can't predict nor control operating system limits for maximal number of open files.
-
msvensson@shellback.(none) authored
into shellback.(none):/home/msvensson/mysql/mysql-4.1-maint
-
msvensson@shellback.(none) authored
- Wait in loop with small sleep until tables has been renamed
-
- 27 Oct, 2006 6 commits
-
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-4.1-ndb
-
jonas@perch.ndb.mysql.com authored
Still leakage, make sure all unlinked operations are put back so they will be release (on failing blob operations, when AO_IgnoreError)
-
msvensson@neptunus.(none) authored
-
Backport of the fix for bug #8143: A date with value 0 is treated as a NULL value
-
- 25 Oct, 2006 6 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug18819
-
kroki/tomash@moonlight.intranet authored
If the error happens during DELETE IGNORE, nothing could be send to the client, thus leaving it frozen expecting the reply. The problem was that if some error occurred, it wouldn't be reported to the client because of IGNORE, but neither success would be reported. MySQL 4.1 would not freeze the client, but will report ERROR 1105 (HY000): Unknown error instead, which is also a bug. The solution is to report success if we are in DELETE IGNORE and some non-fatal error has happened.
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
msvensson@neptunus.(none) authored
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-4.1-ndb
-
msvensson@neptunus.(none) authored
Update the binlog format parse routine to only be avaliable in 5.1 and allow for any binlog_format to be specified
-