running)
I decided to make ps_1general test independent from actual number of
threads running
mysql-test/r/ps_1general.result:
result fixed
mysql-test/t/ps_1general.test:
as i think we don't really care about the number of threads running
i just replace the number with '#'
On exactly-sized Strings, the String::c_ptr() function peeked beyond the
end of the buffer, possibly into unititialized space to see whether the
buffer was NUL-terminated.
In a place that did peek improperly, we now use a c_ptr_safe() function,
which doesn't peek where it shouldn't.
client/sql_string.h:
Back-port String::c_ptr_safe().
sql/item_func.h:
Describe side-effect behavior.
sql/item_strfunc.cc:
Use the "_safe" version of c_ptr to avoid looking for a terminating
NUL character outside the initialized memory area. Valgrind hates it
when one does that, and it theoretically could lead to a SEGV.
sql/sql_string.h:
Back-port String::c_ptr_safe().
mysql-test/r/key.result:
Fixed result after removing wrong bug fix
mysql-test/t/key.test:
Added SHOW CREATE TABLE, which is the proper way to check for table definitions
sql/table.cc:
Reverted wrong bug fix.
The intention with the original code was to show that MySQL treats the first
given unique key as a primary key. Clients can use the marked primary key as a
real primary key to validate row changes in case of conflicting updates. The
ODBC driver (and other drivers) may also use this fact to optimize/check
updates and handle conflicts. The marked key also shows what some engines, like InnoDB or NDB,
will use as it's internal primary key.
For checking if someone has declared a true PRIMARY KEY, one should use 'SHOW CREATE TABLE'
When using a parameter bind MYSQL_TYPE_DATE in a prepared statement,
the time part of the MYSQL_TIME buffer was written to zero in
mysql_stmt_execute(). The param_store_date() function in libmysql.c
worked directly on the provided buffer.
Changed to use a copy of the buffer.
libmysql/libmysql.c:
fix for bug #20152
tests/mysql_client_test.c:
added test for bug#20152
- Added comments.
- Make SEL_ARG::clone() set SEL_ARG::elements in the created copy.
mysql-test/r/range.result:
BUG#16168: Testcase
mysql-test/t/range.test:
BUG#16168: Testcase
heap/hp_test1.c:
Changed type from last commit
mysql-test/mysql-test-run.sh:
Fixed problem with running with --gdb and two masters
Don't disable ndb becasue we run gdb
mysql-test/t/mysqldump.test:
Don't read ~/.my.cnf
sql/ha_ndbcluster.cc:
Portability fix
hp_test2 now works again
Fixed wrong cast, which caused problems with gcc 4.0 and floats in prepared statements (Bug #19694)
heap/hp_test1.c:
Portability fix
heap/hp_test2.c:
Added max_table_size (fixes that hp_test2 works again)
include/my_global.h:
Fixed wrong cast, which caused problems with gcc 4.0 (Bug #19694)
mysys/my_handler.c:
Added missing include file
strings/strtod.c:
Fixed include files
client/mysql.cc:
Remove trailing spaces from help arguments in com_server_help.
Disregard trailing spaces from command in com_help.
mysql-test/r/mysql_client.result:
Test trailing spaces on the help command.
mysql-test/t/mysql_client.test:
Result trailing spaces on the help command.
Fix testNodeRestart -n DuringLCP and others (add stopTest() at end of test :-))
ndb/test/ndbapi/testNodeRestart.cpp:
Fix testNodeRestart -n DuringLCP and others
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.
change default minimum to 3
bug is *very* timing dependent, unable to reproduce here, but theoretically possible.
ndb/src/mgmsrv/ConfigInfo.cpp:
change minimum NoOfFragmentLogFiles to 3
mysql-test/r/grant2.result:
Added results for bug#16180
mysql-test/t/grant2.test:
Added test for bug# 16180
sql/set_var.cc:
Verify user has appropiate rights before setting the sql_log_off system variable.
Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.
Ignoring of these options is documented in the symbolic links
section of the manual.
mysql-test/r/symlink.result:
Modified test result according to fix for BUG#1662.
sql/sql_parse.cc:
Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.
manual merge from 4.0.
support-files/mysql.spec.sh:
Manual merge of the fix for bug#20216.
(became necessary because 4.0 and 4.1 spec files use different file sort order).
mysql-test/r/func_sapdb.result:
test cases for date range edge cases added
mysql-test/r/func_time.result:
test cases for date range edge cases added
mysql-test/t/func_sapdb.test:
test cases for date range edge cases added
mysql-test/t/func_time.test:
test cases for date range edge cases added
'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique
index (or primary key) on a.
There are a number of other similar cases that can be calculated without the
use of a temp table : multi-part unique indexes, primary keys or using GROUP BY
instead of DISTINCT.
When a GROUP BY/DISTINCT clause contains all key parts of a unique
index, then it is guaranteed that the fields of the clause will be
unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
This optimization has two effects:
* there is no need to create a temporary table to compute the
GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP
is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
* this causes the statement in effect to become updatable in Connector/Java
because the result set columns will be direct reference to the primary key of
the table (instead to the temporary table that it currently references).
Implemented a check that will optimize away GROUP BY/DISTINCT for queries like
the above.
Currently it will work only for single non-constant table in the FROM clause.
mysql-test/r/distinct.result:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
mysql-test/t/distinct.test:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- test case
sql/sql_select.cc:
Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
- disable GROUP BY if contains the fields of a unique index.
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.
