- 25 Jun, 2008 1 commit
-
-
Timothy Smith authored
Normalize directory names before adding them to default_directories.
-
- 17 Jun, 2008 3 commits
-
-
Georgi Kodinov authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
Ignore BitKeeper SCCS folders in make-dist
-
- 16 Jun, 2008 1 commit
-
-
Hakan Kuecuekyilmaz authored
-
- 13 Jun, 2008 2 commits
-
-
Joerg Bruehe authored
and the build tag for 5.0.62.
-
joerg@trift-lap.fambruehe authored
-
- 12 Jun, 2008 1 commit
-
-
Georgi Kodinov authored
-
- 10 Jun, 2008 1 commit
-
-
mysqldev authored
-
- 03 Jun, 2008 1 commit
-
-
Georgi Kodinov authored
-
- 02 Jun, 2008 1 commit
-
-
Matthias Leich mleich@mysql.com authored
Fix for this bug and additional improvements/fixes In detail: - Remove unicode attribute from several columns (unicode properties were nowhere needed/tested) of the table tb3 -> The runnability of these tests depends no more on the availibility of some optional collations. - Use a table tb3 with the same layout for all engines to be tested and unify the engine name within the protocols. -> <engine>_trig_<abc>.result have the same content - Do not load data into tb3 if these rows have no impact on result sets - Add tests for NDB (they exist already in 5.1) - "--replace_result" at various places because NDB variants of tests failed with "random" row order in results This fixes a till now unknown weakness within the funcs_1 NDB tests existing in 5.1 and 6.0 - Fix the expected result of ndb_trig_1011ext which suffered from Bug 32656 + disable this test - funcs_1 could be executed with the mysql-test-run.pl option "--reorder", which saves some runtime by optimizing server restarts. Runtimes on tmpfs (one attempt only): with reorder 132 seconds without reorder 183 seconds - Adjust two "check" statements within func_misc.test which were incorrect (We had one run with result set difference though the server worked good.) - minor fixes in comments
-
- 29 May, 2008 1 commit
-
-
Matthias Leich mleich@mysql.com authored
Fix for this bug and a second similar problem found during experimenting. This replaces the first fix (already pushed to 5.1 and merged to 6.0) which - failed in runs with the embedded server - cannot be ported back to 5.0
-
- 28 May, 2008 2 commits
-
-
Georgi Kodinov authored
-
Alexander Barkov authored
Thanks to Paul for preparing the up-to-date files reflecting 4.1 changes.
-
- 27 May, 2008 1 commit
-
-
Georgi Kodinov authored
There was a typo in a error check causing wrong thing to be ckecked and a possible error not being caught. Fixed by using the correct variable to test for malloc() errors.
-
- 25 May, 2008 1 commit
-
-
joerg@trift-lap.fambruehe authored
into trift-lap.fambruehe:/MySQL/M50/work-5.0
-
- 23 May, 2008 1 commit
-
-
Chad MILLER authored
-
- 22 May, 2008 1 commit
-
-
Chad Miller authored
-
- 21 May, 2008 1 commit
-
-
Chad MILLER authored
-
- 18 May, 2008 2 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.0-bugteam
-
gshchepa/uchum@host.loc authored
first row or fails with an error: ERROR 1022 (23000): Can't write; duplicate key in table '' The server uses intermediate temporary table to store updated row data. The first column of this table contains rowid. Current server implementation doesn't reset NULL flag of that column even if the server fills a column with rowid. To keep each rowid unique, there is an unique index. An insertion into an unique index takes into account NULL flag of key value and ignores real data if NULL flag is set. So, insertion of actually different rowids may lead to two kind of problems. Visible effect of each of these problems depends on an initial engine type of temporary table: 1. If multiupdate initially creates temporary table as a MyISAM table (a table contains blob columns, and the create_tmp_table function assumes, that this table is large), it inserts only one single row and updates only rows with one corresponding rowid. Other rows are silently ignored. 2. If multiupdate initially creates MEMORY temporary table, fills it with data and reaches size limit for MEMORY tables (max_heap_table_size), multiupdate converts MEMORY table into MyISAM table and fails with an error: ERROR 1022 (23000): Can't write; duplicate key in table '' Multiupdate has been fixed to update the NULL flag of temporary table rowid columns.
-
- 17 May, 2008 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
temporary variables of 'long' types were used to store ulong values, that causes init_key_cache to receive distorted parameters
-
- 16 May, 2008 9 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-bugteam
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B36011-take2-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
master also, so that we can visually see the slave is the same.
-
gkodinov/kgeorge@magare.gmz authored
with dependent subqueries An IN subquery is executed on EXPLAIN when it's not correlated. If the subquery required a temporary table for its execution not all the internal structures were restored from pointing to the items of the temporary table to point back to the items of the subquery. Fixed by restoring the ref array when a temp tables were used in executing the IN subquery during EXPLAIN EXTENDED.
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
-
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.0-bugteam
-
- 15 May, 2008 1 commit
-
-
cmiller@zippy.cornsilk.net authored
slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
-
- 14 May, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.0-bugteam
-
- 13 May, 2008 3 commits
-
-
gshchepa/uchum@host.loc authored
with previous rows. The WHERE clause containing expression: CONCAT(empty_field1, empty_field2, ..., 'literal constant', ...) REGEXP 'regular expression' may return wrong matches. Optimization of the CONCAT function has been fixed.
-
kent@kent-amd64.(none) authored
into mysql.com:/home/kent/bk/mysql-5.0-release-merge
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.0-bugteam
-
- 12 May, 2008 2 commits
-
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.0-bugteam
-
gshchepa/uchum@host.loc authored
The REPAIR TABLE ... USE_FRM query silently corrupts data of tables with old .FRM file version. The mysql_upgrade client program or the REPAIR TABLE query (without the USE_FRM clause) can't prevent this trouble, because in the common case they don't upgrade .FRM file to compatible structure. 1. Evaluation of the REPAIR TABLE ... USE_FRM query has been modified to reject such tables with the message: "Failed repairing incompatible .FRM file". 2. REPAIR TABLE query (without USE_FRM clause) evaluation has been modified to upgrade .FRM files to current version. 3. CHECK TABLE ... FOR UPGRADE query evaluation has been modified to return error status when .FRM file has incompatible version. 4. mysql_upgrade and mysqlcheck client programs call CHECK TABLE FOR UPGRADE and REPAIR TABLE queries, so their behaviors have been changed too to upgrade .FRM files with incompatible version numbers.
-
- 09 May, 2008 1 commit
-
-
msvensson@pilot.(none) authored
- Backport to 5.0, use --local-load to instruct myqlbinlog where to put the files it generate
-
- 08 May, 2008 1 commit
-
-
into client-10-129-10-147.upp.off.mysql.com:/Users/mattiasj/clones/topush-50-bugteam
-