CMakeLists.txt:
New BitKeeper file ``CMakeLists.txt''
bdb/CMakeLists.txt:
New BitKeeper file ``bdb/CMakeLists.txt''
client/CMakeLists.txt:
New BitKeeper file ``client/CMakeLists.txt''
dbug/CMakeLists.txt:
New BitKeeper file ``dbug/CMakeLists.txt''
extra/CMakeLists.txt:
New BitKeeper file ``extra/CMakeLists.txt''
extra/yassl/CMakeLists.txt:
New BitKeeper file ``extra/yassl/CMakeLists.txt''
extra/yassl/taocrypt/CMakeLists.txt:
New BitKeeper file ``extra/yassl/taocrypt/CMakeLists.txt''
heap/CMakeLists.txt:
New BitKeeper file ``heap/CMakeLists.txt''
innobase/CMakeLists.txt:
New BitKeeper file ``innobase/CMakeLists.txt''
libmysql/CMakeLists.txt:
New BitKeeper file ``libmysql/CMakeLists.txt''
myisam/CMakeLists.txt:
New BitKeeper file ``myisam/CMakeLists.txt''
myisammrg/CMakeLists.txt:
New BitKeeper file ``myisammrg/CMakeLists.txt''
mysys/CMakeLists.txt:
New BitKeeper file ``mysys/CMakeLists.txt''
regex/CMakeLists.txt:
New BitKeeper file ``regex/CMakeLists.txt''
server-tools/CMakeLists.txt:
New BitKeeper file ``server-tools/CMakeLists.txt''
server-tools/instance-manager/CMakeLists.txt:
New BitKeeper file ``server-tools/instance-manager/CMakeLists.txt''
sql/CMakeLists.txt:
New BitKeeper file ``sql/CMakeLists.txt''
sql/examples/CMakeLists.txt:
New BitKeeper file ``sql/examples/CMakeLists.txt''
strings/CMakeLists.txt:
New BitKeeper file ``strings/CMakeLists.txt''
tests/CMakeLists.txt:
New BitKeeper file ``tests/CMakeLists.txt''
vio/CMakeLists.txt:
New BitKeeper file ``vio/CMakeLists.txt''
win/Makefile.am:
New BitKeeper file ``win/Makefile.am''
win/README:
New BitKeeper file ``win/README''
win/build-vs71.bat:
New BitKeeper file ``win/build-vs71.bat''
win/build-vs8.bat:
New BitKeeper file ``win/build-vs8.bat''
win/build-vs8_x64.bat:
New BitKeeper file ``win/build-vs8_x64.bat''
win/configure.js:
New BitKeeper file ``win/configure.js''
zlib/CMakeLists.txt:
New BitKeeper file ``zlib/CMakeLists.txt''
into chilla.local:/home/mydev/mysql-4.1-bug14400
myisam/mi_rkey.c:
Bug#14400 - Query joins wrong rows from table which is
subject of "concurrent insert"
Manual merge from 4.0.
mysql-test/r/myisam.result:
Bug#14400 - Query joins wrong rows from table which is
subject of "concurrent insert"
Manual merge from 4.0.
mysql-test/t/myisam.test:
Bug#14400 - Query joins wrong rows from table which is
subject of "concurrent insert"
Manual merge from 4.0.
subject of "concurrent insert"
Better fix by Monty: "The previous bug fix didn't work
when using partial keys."
mysql-test/r/myisam.result:
Bug#14400 - Query joins wrong rows from table which is
subject of "concurrent insert"
Added test result
mysql-test/t/myisam.test:
Bug#14400 - Query joins wrong rows from table which is
subject of "concurrent insert"
Added test case
table results in table corrupt
Fulltext key has always two keysegs, thus we need to update
FT_SEGS (last) element from seg array in case of compressed table.
Also we must update ft2_keyinfo.
myisam/mi_packrec.c:
Fulltext key has always two keysegs, thus we need to update
FT_SEGS (last) element from seg array in case of compressed table.
Also we must update ft2_keyinfo.
into xiphis.org:/home/antony/work2/mysql-5.0-merge
mysql-test/r/create.result:
Auto merged
mysql-test/r/federated.result:
Auto merged
mysql-test/r/insert_select.result:
Auto merged
mysql-test/r/ps_2myisam.result:
Auto merged
mysql-test/r/ps_3innodb.result:
Auto merged
mysql-test/r/ps_4heap.result:
Auto merged
mysql-test/r/ps_5merge.result:
Auto merged
mysql-test/r/ps_6bdb.result:
Auto merged
mysql-test/r/ps_7ndb.result:
Auto merged
mysql-test/r/strict.result:
Auto merged
mysql-test/r/view.result:
Auto merged
mysql-test/r/warnings.result:
Auto merged
sql/share/errmsg.txt:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
into may.pils.ru:/home/svoj/devel/mysql/BUG18874/mysql-5.0
myisam/sort.c:
Auto merged
mysql-test/r/repair.result:
Auto merged
mysql-test/t/repair.test:
Auto merged
Fixed by moving update_key_parts() down to be after write_index().
myisam/sort.c:
write_index() collects index statistic which is further used in
update_key_parts(). Thus update_key_parts() must be called after
write_index().
mysql-test/r/repair.result:
Test case for bug#18874.
mysql-test/t/repair.test:
Test case for bug#18874.
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
BitKeeper/etc/ignore:
Added */.libs/*
include/my_global.h:
Don't use GNUC min/max operations are they are depricated
myisam/mi_rkey.c:
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.
myisam/mi_test_all.res:
Updated results to match mi_test_all.sh
myisam/mi_test_all.sh:
Removed confusing warning
mysql-test/r/myisam.result:
Added test case for #14400
mysql-test/t/myisam.test:
Added test case for #14400
sql/sql_select.cc:
Fixed valgrind warning (in field_string::val_int())
myisam/mi_uniue.c:mi_check_unique() should skip trailing spaces comparing
TEXT and VARTTEXT key segments.
myisam/mi_unique.c:
Fix for bug #20709: Collation not used in group by on 4.1.
myisam/mi_uniue.c:mi_check_unique() should skip trailing spaces comparing
TEXT and VARTTEXT key segments.
Example: assume, we have a 'char(200) collate utf8_unicode_ci' field,
there are two records with _utf8"0x65" and _utf8"0xC3A9" characters;
these values are equal according
to the utf8_unicode_ci collation, but two 600 byte length corresponding keys:
"0x65<0x20 repeats 599 times>" and "0xC3A9<0x20 repeats 598 times>" are not
equal if we count trailing spaces and it may cause inconsequent behavior.
So, let's pass 1 as the skip_end_space parameter value to the mi_compare_text()
function for proper TEXT and VARTTEXT key segments comparison.
mysql-test/r/ctype_utf8.result:
Fix for bug #20709: Collation not used in group by on 4.1.
- test results.
mysql-test/t/ctype_utf8.test:
Fix for bug #20709: Collation not used in group by on 4.1.
- test case.
Problem described in this bug report affects MyISAM tables only.
Running mysqld --flush instructs mysqld to sync all changes to disk
after each SQL statement. It worked well for INSERT and DELETE
statements, but it did sync for UPDATE only in case if there was
index change (change of colum that has an index). If no updated column
has an index, data wasn't synced to disk.
This fix makes UPDATE statement to sync data to disk even if there is
no index change (that is only data change) and mysqld is run with
--flush option.
myisam/mi_update.c:
Every myisam function that updates myisam table must end with
call to _mi_writeinfo(). If operation (second param of
_mi_writeinfo()) is not 0 it sets share->changed to 1, that is
flags that data has changed. If operation is 0, this function
equals to no-op in this case.
mi_update() must always pass !0 value as operation, since even if
there is no index change there could be data change.
into chilla.local:/home/mydev/mysql-5.0-bug20719
ndb/include/kernel/GlobalSignalNumbers.h:
Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.cpp:
Auto merged
ndb/src/kernel/blocks/dbdict/Dbdict.hpp:
Auto merged
ndb/src/kernel/blocks/dbdih/DbdihMain.cpp:
Auto merged
ndb/src/ndbapi/ndberror.c:
Auto merged
sql/ha_ndbcluster.cc:
Auto merged
sql/handler.h:
Auto merged
sql/sql_base.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
Fixed a possible problem with reading of dynamic records
when a write cache is active. The cache must be flushed
whenever a part of the file in the write cache is to be
read.
Added a read optimization to _mi_read_dynamic_record().
No test case. This was a hypothetical but existing problem.
myisam/mi_dynrec.c:
Bug#20719 - Reading dynamic records with write buffer could fail
Fixed a possible problem with reading of dynamic records
when a write cache is active. The cache must be flushed
whenever a part of the file in the write cache is to be
read. This must be done before the read of the header
and before the read of the rest block.
Renamed the 'flag' and 'skipp_deleted_blocks' variables.
Added a read optimization to _mi_read_dynamic_record()
that was present in _mi_read_rnd_dynamic_record() already.
After _mi_get_block_info() we have some bytes of the record
in the header buffer already. No need to read them again.
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
myisam/mi_create.c:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/myisam.test:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_insert.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_trigger.cc:
Auto merged
support-files/mysql.spec.sh:
Auto merged
mysql-test/r/federated.result:
Manual merge.
mysql-test/t/federated.test:
Manual merge.
into bodhi.local:/opt/local/work/mysql-5.0-runtime-merge-41
BitKeeper/etc/ignore:
auto-union
libmysqld/Makefile.am:
Auto merged
myisam/mi_create.c:
Auto merged
mysql-test/r/date_formats.result:
Auto merged
mysql-test/t/date_formats.test:
Auto merged
sql/Makefile.am:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_class.h:
Auto merged
support-files/mysql.spec.sh:
Auto merged
mysql-test/r/myisam.result:
Manual merge.
mysql-test/t/myisam.test:
Manual merge.
sql/set_var.cc:
Manual merge.
sql/set_var.h:
Manual merge.
sql/sql_cache.cc:
Manual merge.
sql/sql_class.cc:
Manual merge.
"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.
myisam/mi_create.c:
Bug#8706
When creating a temporary table with directory override, ensure that
the real filename is using the hidden temporary name otherwise
multiple clients cannot have same named temporary tables without
conflict.
mysql-test/r/myisam.result:
Bug#8706
Test for bug
mysql-test/t/myisam.test:
Bug#8706
Test for bug
into mysql.com:/home/mydev/mysql-5.0-ateam
myisam/mi_key.c:
Auto merged
mysql-test/r/gis-rtree.result:
Auto merged
mysql-test/t/gis-rtree.test:
Auto merged
myisam/mi_check.c:
SCCS merged
into mysql.com:/home/mydev/mysql-5.0-ateam
libmysqld/libmysqld.c:
Auto merged
myisam/mi_rkey.c:
Auto merged
mysql-test/r/func_sapdb.result:
Auto merged
mysql-test/r/symlink.result:
Auto merged
mysql-test/t/func_sapdb.test:
Auto merged
scripts/make_binary_distribution.sh:
Auto merged
sql/item_geofunc.h:
Auto merged
sql/item_timefunc.cc:
Auto merged
sql/sql_class.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
libmysqld/lib_sql.cc:
Manual merge
mysql-test/r/func_time.result:
Manual merge
mysql-test/r/gis.result:
Manual merge
mysql-test/t/func_time.test:
Manual merge
mysql-test/t/gis.test:
Manual merge
sql-common/client.c:
Manual merge
into mysql.com:/home/mydev/mysql-5.0-ateam
myisam/mi_create.c:
Auto merged
mysql-test/r/ctype_utf8.result:
Auto merged
mysql-test/r/key.result:
Auto merged
mysql-test/r/myisam.result:
Auto merged
mysql-test/t/ctype_utf8.test:
Auto merged
mysql-test/t/key.test:
Auto merged
mysql-test/t/myisam.test:
Auto merged
sql/opt_sum.cc:
Auto merged
sql/table.cc:
Auto merged
support-files/mysql.spec.sh:
Auto merged
sql/field.cc:
Manual merge
into mysql.com:/home/mydev/mysql-4.1-bug14400
myisam/mi_rkey.c:
Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
Manual merge
sql/sql_class.cc:
Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
Manual merge
It was possible that fetching a record by an exact key value
(including the record pointer) could return a record with a
different key value. This happened only if a concurrent insert
added a record with the searched key value after the fetching
statement locked the table for read.
The search succeded on the key value, but the record was
rejected as it was past the file length that was remembered
at start of the fetching statement. With other words it was
rejected as being a concurrently inserted record.
The action to recover from this problem was to fetch the
record that is pointed at by the next key of the index.
This was repeated until a record below the file length was
found.
I do now avoid this loop if an exact match was searched.
If this match is beyond the file length, it is now treated
as "key not found". There cannot be another key with the
same record pointer.
myisam/mi_rkey.c:
Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
Added a check for exact key match before searching for
the next key that was not concurrently inserted. If an
exact key match finds a concurrently inserted row, this
must be treated as "key not found".
sql/sql_class.cc:
Bug#14400 - Query joins wrong rows from table which is subject of "concurrent insert"
Fixed some DBUG_ENTER strings.
A corrupt table with dynamic record format can crash the
server when trying to select from it.
I fixed the crash that resulted from the particular type
of corruption that has been reported for this bug.
No test case. To test it, one needs a table with a very special
corruption. The bug report contains a file with such a table.
myisam/mi_dynrec.c:
Bug#19835 - Binary copy of corrupted tables crash the server when issuing a query
Added a protection against corrupted records. A dynamic
record header with invalid 'next' pointer could trigger
the assert in _mi_get_block_info(). Now I avoid this by
reporting a corruption error.
CHECK TABLE could complain about a fully intact spatial index.
A wrong comparison operator was used for table checking.
The result was that it checked for non-matching spatial keys.
This succeeded if at least two different keys were present,
but failed if only the matching key was present.
I fixed the key comparison.
myisam/mi_check.c:
Bug#17877 - Corrupted spatial index
Fixed the comparison operator for checking a spatial index.
Using MBR_EQUAL | MBR_DATA to compare for equality and
include the data pointer in the comparison. The latter
finds the index entry that points to the current record.
This is necessary for non-unique indexes.
The old operator, SEARCH_SAME, is unknown to the rtree
search functions and handled like MBR_DISJOINT.
myisam/mi_key.c:
Bug#17877 - Corrupted spatial index
Added a missing DBUG_RETURN.
myisam/rt_index.c:
Bug#17877 - Corrupted spatial index
Included the data pointer in the copy of the search key.
This is necessary for searching the index entry that points
to a specific record if the search_flag contains MBR_DATA.
myisam/rt_mbr.c:
Bug#17877 - Corrupted spatial index
Extended the RT_CMP() macro with an assert for an
unexpected comparison operator.
mysql-test/r/gis-rtree.result:
Bug#17877 - Corrupted spatial index
The test result.
mysql-test/t/gis-rtree.test:
Bug#17877 - Corrupted spatial index
The test case.
Very complex select statements can create temporary tables
that are too big to be represented as a MyISAM table.
This was not checked at table creation time, but only at
open time. The result was an attempt to delete the
"impossible" table.
But if the server is built --with-raid, MyISAM tries to
open the table before deleting the files. It needs to find
out if the table uses the raid support and how many raid
chunks there are. This is done with an open "for repair",
which will almost always succeed.
But in this case we have an "impossible" table. The open
failed. Hence the files were not deleted. Also the error
message was a bit unspecific.
I turned an open error in this situation into the assumption
of having no raid support on the table. Thus the normal data
file is tried to be deleted. This may however leave existing
raid chunks behind.
I also added a check in mi_create() to prevent the creation
of an "impossible" table. A more decriptive error message is
given in this case.
No test case. The required select statement is way too
large for the test suite. I added a test script to the
bug report.
myisam/mi_create.c:
Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
Added a check to mi_create() that the table description
header of the index file does not exceed 64KB. The header
has only 16 bits to encode its length.
myisam/mi_delete_table.c:
Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
Interpret error in table open as not having a raid
configuration on the tbale. Thus try to delete the
normal data file, but leave behind raid chunks if
they exist.
CHECK TABLE did temporarily clear the auto_increment value.
It runs with a read lock, allowing other readers and
conurrent INSERTs. The latter could grab the wrong value
in this moment.
CHECK TABLE does no longer modify the auto_increment value.
Not even for a short moment.
myisam/mi_check.c:
Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
In chk_key() and update_auto_increment_key() in the repair_only
case, do not touch info->s->state.auto_increment. Especially
chk_key() can be called from CHECK TABLE with a read lock.
Concurrent inserts could grab a temporarily changed value.
Added minor style fixes.
myisam/mi_key.c:
Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
Changed update_auto_increment() to retrieve_auto_increment()
to reflect that it does not change the auto_increment by
itself any more. This must now be done externally if needed.
myisam/mi_update.c:
Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
Added explicit update of info->s->state.auto_increment
after the change from update_auto_increment() to
retrieve_auto_increment().
myisam/mi_write.c:
Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
Added explicit update of info->s->state.auto_increment
after the change from update_auto_increment() to
retrieve_auto_increment().
myisam/myisamdef.h:
Bug#19604 - CHECK TABLE with concurrent INSERT can reset auto_increment
Changed update_auto_increment() to retrieve_auto_increment()
to reflect that it does not change the auto_increment by
itself any more. This must now be done externally if needed.
Write operations on tables created in 4.x with index on variable
length column results in index crash. Even REPAIR TABLE wasn't able
to fix broken index.
Problem was that packed key length size wasn't restored correctly.
In 5.0 packed key length size is either 1 or 2. In 4.x this length
is always 2, but is saved as 0.
This fix ensures that key length size is restored correctly for 4.x
tables.
myisam/mi_key.c:
Ensure that pack_length is either 1 or 2 (compatibility with 4.x).
myisam_ftdump options: --help first, then rest in
lexical order.
myisam/myisam_ftdump.c:
myisam_ftdump options: --help first, then rest in
lexical order.
Updating data in HEAP table with BTREE index results in wrong index_length
counter value, which keeps growing after each update.
When inserting new record into tree counter is incremented by:
sizeof(TREE_ELEMENT) + key_size + tree->size_of_element
But when deleting element from tree it doesn't decrement counter by key_size:
sizeof(TREE_ELEMENT) + tree->size_of_element
This fix makes accurate allocated memory counter for tree. That is
decrease counter by key_size when deleting tree element.
heap/hp_delete.c:
Added size of the key to tree_delete() for accurate allocated memory counter.
include/my_tree.h:
Added size of the key to tree_delete() for accurate allocated memory counter.
myisam/myisamlog.c:
Added size of the key to tree_delete() for accurate allocated memory counter.
mysql-test/r/heap_btree.result:
Testcase for BUG#18160.
mysql-test/t/heap_btree.test:
Testcase for BUG#18160.
mysys/tree.c:
Added size of the key to tree_delete() for accurate allocated memory counter.
Note that this size is optional. If one doesn't need precise counter it is safe
to pass 0 as key_size.
Retrieving data from compressed MyISAM table which is bigger than 4G on 32-bit box
with mmap() support results in server crash.
mmap() accepts length of bytes to be mapped in second param, which is 32-bit
size_t. But we pass data_file_length, which is 64-bit my_off_t. As a result only
first data_file_length % 4G were mapped.
This fix adds additional condition for mmap() usage, that is use mmap() for
compressed table which size is no more than 4G on 32-bit platform.
myisam/mi_packrec.c:
Use mmap() for compressed table which size is no more than 4G on 32-bit platform.
Whenever 'myisamchk' needed to recreate a table,
the auto increment information was lost.
Now the forgotten element of the table creation
information is set correctly.
myisam/mi_check.c:
Bug#10405 - myisamchk damages auto_increment columns when changing character set
Added some DBUG statements.
Enabled 'with_auto_increment' in 'create_info'
when recreating a table.
