- 31 Mar, 2008 1 commit
-
-
mleich@five.local.lan authored
Bug#35335 funcs_1: Some tests fail within load_file during pushbuild runs Solution: 1. Move files with input data used in load_file, load data etc. from suite/funcs_1/<whatever> to std_data 2. Use for testsuite funcs_1 the server option --secure-file-priv=<MYSQLTEST_VARDIR> 3. Outfiles have to be stored under MYSQLTEST_VARDIR + changes according to WL#4304 Cleanup in funcs_1 tests - backport of fixes/improvements made in 5.1 to 5.0 The differences between scripts in 5.0 and 5.1 cause much additional and annoying work during any upmerge. - replace error numbers with names - improved comments - improved formatting - Unify storage engine names so that result files for storage engine variants do not differ (some tests) - remove a script no more used (tests are done in other scripts)
-
- 27 Mar, 2008 4 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
df@pippilotta.erinye.com authored
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
tsmith@rhel5-ia64-a.mysql.com authored
into rhel5-ia64-a.mysql.com:/data0/tsmith/build/50
-
- 26 Mar, 2008 4 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-build
-
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 3 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
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.
-
- 22 Mar, 2008 2 commits
-
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/build/mysql-5.0-build
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/build/mysql-4.1-build
-
- 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 10 commits
-
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
isn't running Pass the process id of the manager as a parameter to "wait_for_pid" and if the manager isn't running, then do not continue to wait. Also, capture the error message of our process-existence test, "kill -0", as we expect errors and shouldn't pass them to the user. Additionally, be a bit more descriptive of what the problem is.
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/build/50
-
tsmith@ramayana.hindu.god authored
into ramayana.hindu.god:/home/tsmith/m/bk/build/50
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M50/man8-5.0
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
joerg@trift2. authored
-
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.
-
joerg@trift2. authored
into trift2.:/MySQL/M41/push-4.1
-
- 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 3 commits
-
-
-
davi@mysql.com/endora.local authored
-
into mysql.com:/data0/mysqldev/my/build-200802282059-4.1.24/mysql-4.1-release
-
- 15 Mar, 2008 1 commit
-
-
istruewing@stella.local authored
into stella.local:/home2/mydev/mysql-5.0-axmrg
-
- 14 Mar, 2008 7 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
-
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
-