- 27 Mar, 2008 3 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
- 26 Mar, 2008 5 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
gshchepa/uchum@host.loc authored
View definition as SELECT ... FROM DUAL WHERE ... has valid syntax, but use of such view in SELECT or SHOW CREATE VIEW syntax causes unexpected syntax error. Server omits FROM DUAL clause when storing view body string in a .frm file for further evaluation. However, syntax of SELECT-witout-FROM query is more restrictive than SELECT FROM DUAL syntax, and doesn't allow the WHERE clause. NOTE: this syntax difference is not documented. View registration procedure has been modified to preserve original structure of view's body.
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
- 25 Mar, 2008 4 commits
-
-
malff@lambda.hsd1.co.comcast.net. authored
instructions) This bug can not be reproduced in the current version, adding the test case to the test suite for coverage, no code change.
-
gshchepa/uchum@host.loc authored
Minor test case cleanup after bug#34529.
-
anozdrin/alik@quad.opbmk authored
into quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged
-
svoj@mysql.com/june.mysql.com authored
localhost/default port When creating federated table that points to unspecified host or localhost on unspecified port or port is 0, small memory leak occurs. This happens because we make a copy of unix socket path, which is never freed. With this fix we do not make a copy of unix socket path, instead share->socket points to MYSQL_UNIX_ADDR constant directly. This fix is covered by a test case for BUG34788. Affects 5.0 only.
-
- 24 Mar, 2008 1 commit
-
-
mhansson/autopush@riffraff.(none) authored
into riffraff.(none):/data0/autopush/my50-bug34529
-
- 23 Mar, 2008 1 commit
-
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/33334/my50-33334
-
- 21 Mar, 2008 2 commits
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B26461-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
The bool data type was redefined to BOOL (4 bytes on windows). Removed the #define and fixed some of the warnings that were uncovered by this. Note that the fix also disables 2 warnings : 4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning) 4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation These warnings will be handled in a separate bug, as they are performance related or bogus. Fixed to int the return type of functions that return more than 2 distinct values.
-
- 20 Mar, 2008 3 commits
-
-
svoj@mysql.com/june.mysql.com authored
correctly - crashes server ! Creating federated table with connect string containing empty (zero-length) host name and port is evaluated as 0 (port is incorrect, omitted or 0) crashes server. This happens because federated calls strcmp() with NULL pointer. Fixed by avoiding strcmp() call if hostname is set to NULL.
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
- 19 Mar, 2008 5 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/home/uchum/work/5.0-opt
-
davi@mysql.com/endora.local authored
The problem is that unimplemented WIN32 version of pthread_kill is returning ESRCH no matter the arguments, causing calls to mysqld_list_processes to set the procinfo to dead because pthread_kill returns non zero. The dead procinfo would show up on a second invocation of show processlist.
-
mhansson/martin@riffraff.(none) authored
When swapping out heap I_S tables to disk, this is done after plan refinement. Thus, READ_RECORD::file will still point to the (deleted) heap handler at start of execution. This causes segmentation fault if join buffering is used and the query is a star query where the result is found to be empty before accessing some table. In this case that table has not been initialized (i.e. had its READ_RECORD re-initialized) before the cleanup routine tries to close the handler. Fixed by updating READ_RECORD::file when changing handler.
-
kaa@kaamos.(none) authored
into kaamos.(none):/data/src/opt/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
Before breaking the connection we have to check that there's no query executing at the moment. Otherwise it can lead to crash in embedded server.
-
- 18 Mar, 2008 2 commits
-
-
svoj@mysql.com/april.(none) authored
-
anozdrin/alik@quad.opbmk authored
into quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged
-
- 17 Mar, 2008 2 commits
-
-
-
davi@mysql.com/endora.local authored
-
- 15 Mar, 2008 1 commit
-
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
- 14 Mar, 2008 11 commits
-
-
antony@pcg5ppc.xiphis.org authored
into pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0
-
davi@mysql.com/endora.local authored
The problem was that the COM_STMT_SEND_LONG_DATA was sending a response packet if the prepared statement wasn't found in the server (due to reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE should not send any packets, even error packets should not be sent since they are not expected by the client API. The solution is to clear generated during the execution of the aforementioned commands and to skip resend of prepared statement commands. Another fix is that if the connection breaks during the send of prepared statement command, the command is not sent again since the prepared statement is no longer in the server.
-
istruewing@stella.local authored
-
gshchepa/uchum@host.loc authored
Queries like: SELECT ROW(1, 2) IN (SELECT t1.a, 2) FROM t1 GROUP BY t1.a or SELECT ROW(1, 2) IN (SELECT t1.a, 2 FROM t2) FROM t1 GROUP BY t1.a lead to assertion failure in the Item_in_subselect::row_value_transformer method in debugging build, or to unexpected error message in release build: ERROR 1247 (42S22): Reference '<list ref>' not supported (forward reference in item list) Unexpected error message and assertion failure have been eliminated.
-
antony@pcg5ppc.xiphis.org authored
into pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0
-
antony@pcg5ppc.xiphis.org authored
into pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
mkindahl@dl145h.mysql.com authored
into dl145h.mysql.com:/data0/mkindahl/mysql-5.0-rpl
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
svoj@june.mysql.com authored
into mysql.com:/home/svoj/devel/mysql/BUG28248/mysql-5.0-engines
-
svoj@mysql.com/june.mysql.com authored
When there are no underlying tables specified for a merge table, SHOW CREATE TABLE outputs a statement that cannot be executed. The same is true for mysqldump (it generates dumps that cannot be executed). This happens because SQL parser does not accept empty UNION() clause. This patch changes the following: - it is now possible to execute CREATE/ALTER statement with empty UNION() clause. - the same as above, but still worth noting: it is now possible to remove underlying tables mapping using ALTER TABLE ... UNION=(). - SHOW CREATE TABLE does not output UNION() clause if there are no underlying tables specified for a merge table. This makes mysqldump slightly smaller.
-