An error occurred fetching the project authors.
- 16 Jan, 2008 1 commit
-
-
istruewing@stella.local authored
at page 1024 with ucs2_bin Post-pushbuild fix. Moved test from myisam.test to ctype_ucs2_def.test. UCS2 is not always available.
-
- 18 Dec, 2007 1 commit
-
-
istruewing@stella.local authored
at page 1024 with ucs2_bin Inserting strings with a common prefix into a table with characterset UCS2 corrupted the table. An efficient search method was used, which compares end space with ASCII blank. This doesn't work for character sets like UCS2, which do not encode blank like ASCII does. Use the less efficient search method _mi_seq_search() for charsets with mbminlen > 1.
-
- 14 Nov, 2007 1 commit
-
-
istruewing@stella.local authored
Post-pushbuild fix Added a purecov comment and a test for coverage of parallel enable keys.
-
- 06 Nov, 2007 1 commit
-
-
istruewing@stella.local authored
Disabling and enabling indexes on a non-empty table grows the index file. Disabling indexes just sets a flag per non-unique index and does not free the index blocks of the affected indexes. Re-enabling indexes creates new indexes with new blocks. The old blocks remain unused in the index file. Fixed by dropping and re-creating all indexes if non-empty disabled indexes exist when enabling indexes. Dropping all indexes resets the internal end-of-file marker to the end of the index file header. It also clears the root block pointers of every index and clears the deleted blocks chains. This way all blocks are declared as free.
-
- 22 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
When processing the USE/FORCE index hints the optimizer was not checking if the indexes specified are enabled (see ALTER TABLE). Fixed by: Backporting the fix for bug 20604 to 5.0
-
- 16 Mar, 2007 1 commit
-
-
istruewing@chilla.local authored
when index is used When the table contained TEXT columns with empty contents ('', zero length, but not NULL) _and_ strings starting with control characters like tabulator or newline, the empty values were not found in a "records in range" estimate. Hence count(*) missed these records. The reason was a different set of search flags used for key insert and key range estimation. I decided to fix the set of flags used in range estimation. Otherwise millions of databases around the world would require a repair after an upgrade. The consequence is that the manual must be fixed, which claims that TEXT columns are compared with "end space padding". This is true for CHAR/VARCHAR but wrong for TEXT. See also bug 21335.
-
- 15 Feb, 2007 1 commit
-
-
igor@olga.mysql.com authored
were evaluated. According to the new rules for string comparison partial indexes on text columns can be used in the same cases when partial indexes on varchar columns can be used.
-
- 24 Jan, 2007 3 commits
-
-
istruewing@chilla.local authored
After merge fix
-
istruewing@chilla.local authored
Fixed test. On 32-bit machines which compile without -DBIG_TABLES, MAX_ROWS is truncated to a 32-bit value. Using a value below 4G is portable.
-
svoj@mysql.com/june.mysql.com authored
-
- 19 Jan, 2007 1 commit
-
-
istruewing@chilla.local authored
-
- 17 Jan, 2007 3 commits
-
-
msvensson@pilot.mysql.com authored
Bug #25000 myisam.test fails on 'pb-valgrind-*' Valgrind - Move tests that need symlink to symlink.test
-
msvensson@pilot.mysql.com authored
-
msvensson@pilot.mysql.com authored
-
- 05 Jan, 2007 1 commit
-
-
istruewing@chilla.local authored
The function mi_get_pointer_length() computed too small pointer size for very large tables. Inserted missing 'else' between the branches for very large tables.
-
- 20 Dec, 2006 1 commit
-
-
svoj@mysql.com/april.(none) authored
An update that used a join of a table to itself and modified the table on one side of the join reported the table as crashed or updated wrong rows. Fixed by creating temporary table for self-joined multi update statement.
-
- 15 Dec, 2006 1 commit
-
-
thek@kpdesk.mysql.com authored
- Result file was not properly committed. - Update result file to match the new test case.
-
- 14 Dec, 2006 3 commits
-
-
tsmith/tim@siva.hindu.god authored
-
thek@kpdesk.mysql.com authored
Merged 4.1->5.0. Updated myisam.test
-
thek@kpdesk.mysql.com authored
- When this bug was corrected it changed the behavior for data/index directory in the myisam test case. - This patch moves the OS depending tests to a non-windows test file.
-
- 09 Oct, 2006 3 commits
-
-
istruewing@chilla.local authored
After merge fix. MyISAM version 10.
-
istruewing@chilla.local authored
OPTIMIZE TABLE with myisam_repair_threads > 1 performs a non-quick parallel repair. This means that it does not only rebuild all indexes, but also the data file. Non-quick parallel repair works so that there is one thread per index. The first of the threads rebuilds also the new data file. The problem was that all threads shared the read io cache on the old data file. If there were holes (deleted records) in the table, the first thread skipped them, writing only contiguous, non-deleted records to the new data file. Then it built the new index so that its entries pointed to the correct record positions. But the other threads didn't know the new record positions, but put the positions from the old data file into the index. The new design is so that there is a shared io cache which is filled by the first thread (the data file writer) with the new contiguous records and read by the other threads. Now they know the new record positions. Another problem was that for the parallel repair of compressed tables a common bit_buff and rec_buff was used. I changed it so that thread specific buffers are used for parallel repair. A similar problem existed for checksum calculation. I made this multi-thread safe too.
-
gkodinov/kgeorge@macbook.local authored
Currently SQL_BIG_RESULT is checked only at compile time. However, additional optimizations may take place after this check that change the sort method from 'filesort' to sorting via index. As a result the actual plan executed is not the one specified by the SQL_BIG_RESULT hint. Similarly, there is no such test when executing EXPLAIN, resulting in incorrect output. The patch corrects the problem by testing for SQL_BIG_RESULT both during the explain and execution phases.
-
- 07 Sep, 2006 1 commit
-
-
istruewing@chilla.local authored
"concurrent insert" Additional fix for full keys and test case.
-
- 29 Aug, 2006 1 commit
-
-
istruewing@chilla.local authored
subject of "concurrent insert" Better fix by Monty: "The previous bug fix didn't work when using partial keys."
-
- 25 Aug, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
Default is "var/tmp"
-
- 10 Aug, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Better bug fix for #14400 "Query joins wrong rows from table which is subject of "concurrent insert"" The previous bug fix didn't work when using partial keys. Don't use GNUC min/max operations are they are depricated. Fixed valgrind warning
-
- 10 Jul, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 06 Jul, 2006 1 commit
-
-
acurtis@xiphis.org authored
"temporary table with data directory option fails" myisam should not use user-specified table name when creating temporary tables and use generated connection specific real name. Test included.
-
- 21 Jun, 2006 1 commit
-
-
svoj@may.pils.ru authored
functions in queries Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE) results in error 124 (wrong index) from storage engine. The problem was that optimizer use disabled index to optimize MAX()/MIN(). Normally it must skip disabled index and perform table scan. This patch skips disabled indexes for min/max optimization.
-
- 19 Jun, 2006 1 commit
-
-
svoj@may.pils.ru authored
Certain updates of table joined to self results in unexpected behavior. The problem was that record cache was mistakenly enabled for self-joined table updates. Normally record cache must be disabled for such updates. Fixed wrong condition in code that determines whether to use record cache for self-joined table updates. Only MyISAM tables were affected.
-
- 10 Mar, 2006 1 commit
-
-
ingo@mysql.com authored
For "count(*) while index_column = value" an index read is done. It consists of an index scan and retrieval of each key. For efficiency reasons the index scan stores the key in the special buffer 'lastkey2' once only. At the first iteration it notes this fact with the flag HA_STATE_RNEXT_SAME in 'info->update'. For efficiency reasons, the key retrieval for blobs does not allocate a new buffer, but uses 'lastkey2'... Now I clear the HA_STATE_RNEXT_SAME flag whenever the buffer has been polluted. In this case, the index scan copies the key value again (and sets the flag again).
-
- 01 Feb, 2006 1 commit
-
-
ingo@mysql.com authored
There are (at least) two implementations of the checksum computation. One is in MyISAM for the quick checksum. It is executed on every row change. The other is in the SQL layer for the extended checksum. It retrieves all rows of a table via the respective storage engine. In former MySQL versions varchars were stored with their maximum length, but now with their real length similar to blobs. This change had been forgotten to take care of in the extended checksum calculation. Hence too much data was checksumed. In MyISAM this change had been taken care of already. Only the real data is included in the checksum. I changed mysql_checksum_table() so that it uses the length information of true varchar fields instead of the field length like in former varchar implementations.
-
- 22 Nov, 2005 1 commit
-
-
causes change of test behaviour
-
- 15 Nov, 2005 1 commit
-
-
ingo@mysql.com authored
After merge fix.
-
- 07 Nov, 2005 1 commit
-
-
ingo@mysql.com authored
Initialized usable_keys from table->keys_in_use instead of ~0 in test_if_skip_sort_order(). It was possible that a disabled index was used for sorting.
-
- 28 Oct, 2005 1 commit
-
-
sergefp@mysql.com authored
do advance the source pointer over 2 bytes that specify value length.
-
- 21 Oct, 2005 1 commit
-
-
sergefp@mysql.com authored
added "nulls_ignored" index statistics collection method for MyISAM tables. (notification trigger: this is about BUG#9622).
-
- 29 Sep, 2005 1 commit
-
-
sergefp@mysql.com authored
"t.key BETWEEN c1 AND c2" and c1 = c2 -> can access table t using "t.key = c1".
-
- 23 Sep, 2005 1 commit
-
-
sergefp@mysql.com authored
-