- 28 Feb, 2006 1 commit
-
-
evgen@moonbone.local authored
used In a simple queries a result of the GROUP_CONCAT() function was always of varchar type. But if length of GROUP_CONCAT() result is greater than 512 chars and temporary table is used during select then the result is converted to blob, due to policy to not to store fields longer than 512 chars in tmp table as varchar fields. In order to provide consistent behaviour, result of GROUP_CONCAT() now will always be converted to blob if it is longer than 512 chars. Item_func_group_concat::field_type() is modified accordingly.
-
- 21 Feb, 2006 4 commits
-
-
petr@mysql.com authored
into mysql.com:/home/cps/mysql/devel/im/5.0-im-fix-race
-
petr@mysql.com authored
duration of the whole 'flush instances'. As a consequence, it was possible to query instance map, while it is in the inconsistent state. The patch was reworked after review.
-
petr@mysql.com authored
into mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message
-
petr@mysql.com authored
connections correctly". Recommit with the max timeout value in sync with the comment.
-
- 20 Feb, 2006 5 commits
-
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-5.0.w2645
-
holyfoot@deer.(none) authored
-
knielsen@mysql.com authored
into mysql.com:/usr/local/mysql/mysql-5.0
-
knielsen@mysql.com authored
fails with --vardir option.
-
igor@rurik.mysql.com authored
into rurik.mysql.com:/home/igor/dev/mysql-5.0-0
-
- 18 Feb, 2006 6 commits
-
-
guilhem@mysql.com authored
-
guilhem@mysql.com authored
Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the original bug's title isn't the simplest symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N (where N is interpreted like if SQL_MODE was a field of type SET), so this bug affected recovery from binlogs if the server was running with certain SQL_MODE values, for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people had to edit mysqlbinlog's output.
-
guilhem@mysql.com authored
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master, slave would stop and complain that error code between him and master mismatch. To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function call as SELECT instead of as DO (see revision comment of sp_head.cc for more). And: minor wording change in the help text. This cset will cause conflicts in 5.1, I'll merge.
-
guilhem@mysql.com authored
Fix for BUG#16559 "Replication Problems with Non transactional tables inside an interrupted trans.": problem was: when a connection disconnects having an open transaction affecting MyISAM and InnoDB, the ROLLBACK event stored in the binary log contained a non-zero error code (1053 because of the disconnection), so when slave applied the transaction, slave complained that its ROLLBACK succeeded (error_code=0) while master's had 1053, so slave stopped. But internally generated binlog events such as this ROLLBACK should always have 0 as error code, as is true in 4.1 and was accidentally broken in 5.0, so that there is no false alarm.
-
holyfoot@deer.(none) authored
-
petr@mysql.com authored
-
- 17 Feb, 2006 8 commits
-
-
petr@mysql.com authored
into mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message
-
jimw@mysql.com authored
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-clean
-
paul@snake-hub.snake.net authored
into snake-hub.snake.net:/src/extern/MySQL/bk/mysql-5.0
-
paul@snake-hub.snake.net authored
Tweak --check-upgrade help text.
-
evgen@moonbone.local authored
into moonbone.local:/work/15706-bug-5.0-mysql
-
holyfoot@mysql.com authored
into mysql.com:/home/hf/work/mysql-5.0.w2645
-
holyfoot@deer.(none) authored
necessary implementation in the server mysql_upgrade script added
-
- 16 Feb, 2006 9 commits
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug8841
-
evgen@moonbone.local authored
-
paul@snake-hub.snake.net authored
Fix out of order options.
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug8841
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug8841
-
msvensson@neptunus.(none) authored
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug8841
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/5.0/bug17411-thisisaverylongnamethatshouldbewaylongerthanthe128limitthatweprivouslyhadbutireallywantotestitandseethatitdoesreallywork.nowitshouldbeabout160charslongnonow.iwonderifanythingwillchokeornotwiththisoutrageouslylongpathname
-
- 15 Feb, 2006 7 commits
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-clean
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-clean
-
evgen@moonbone.local authored
If item->cached_table is set, find_field_in_tables() returns found field even if it doesn't belong to current select. Because Item_field::fix_fields doesn't expect such behaviour, reported bug occurs. Item_field::fix_fields() was modifed to detect when find_field_in_tables() can return field from outer select and process such fields accordingly. In order to ease this code which was searching and processing outed fields was moved into separate function called Item_field::fix_outer_field().
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-4.1-clean
-
msvensson@devsrv-b.mysql.com authored
- Init sql_state in mysql_stmt_init
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-