Select of the test could not perform deterministically, because the table remains to be
updatable by the running event handler.
Fixed with changing verification to use a logical values instead of comparison
with a pre-recorded results.
The problem is that since MyISAM's concurrent_insert is on by
default some concurrent SELECT statements might not see changes
made by INSERT statements in other connections, even if the
INSERT statement has returned.
The solution is to disable concurrent_insert so that INSERT
statements returns after the data is actually visible to other
statements.
100% effectively on Windows
The mysqltest docs state that the 'replace_result' command
doesn't perform any escape processing.
However the current implementation was processing backslash
escapes in the from/to strings.
This prevents replacing e.g. patch on windows (where backslash
is used as a path separator).
Fixed by removing the backslash escape processing from
'replace_result'.
Bug#36033 - Test funcs_1.processlist_val_ps fails on Windows
Bug#36034 - Test parts.part_supported_sql_func_<eng> fails on Windows
Bug#36036 - Test parts.partition_alter1_<eng> fails on Windows
Bug#36037 - Test parts.partition_alter2_<eng> fails on Windows
Bug#36038 - Test parts.partition_basic_<engine> failing on Windows
Bug#36039 - Test parts.partition_engine_<eng> fails on Windows
Bug#36040 - Test parts.partition_syntax_<eng> fails on Windows
Changeset to fix multiple 5.1.24-rc build bugs on Windows platforms.
Many of these bugs had the same root causes.
for ENGINE=MRG_MYISAM (should be optimized out).
Before WL#3281 MERGE engine had the HA_NOT_EXACT_COUNT flag
unset, and it worked with COUNT optimization as desired.
After the removal of the HA_NOT_EXACT_COUNT flag neither
HA_STATS_RECORDS_IS_EXACT (opposite to former HA_NOT_EXACT_COUNT
flag) nor modern HA_HAS_RECORDS flag were not added to MERGE
table flag mask.
1. The HA_HAS_RECORDS table flag has been set.
2. The ha_myisammrg::records method has been overridden to
calculate total number of records in underlying tables.
When a zero length is provided to the my_decimal_length_to_precision
function along with unsigned_flag set to false it returns a negative value.
For queries that employs temporary tables may cause failed assertion or
excessive memory consumption while temporary table creation.
Now the my_decimal_length_to_precision and the my_decimal_precision_to_length
functions take unsigned_flag into account only if the length/precision
argument is non-zero.
Fix for
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)
The function test_if_skip_sort_order ignored any covering index used for ref
access of a table in a query with ORDER BY if this index was incompatible
with the ORDER BY list and there was another covering index compatible with
this list.
As a result sub-optimal execution plans were chosen for some queries with
ORDER BY clause.
impossible WHERE/HAVING clause
(subselect_single_select_engine::exec).
Allocation and initialization of joined table list t1, t2... of
subqueries like:
NOT IN (SELECT ... FROM t1,t2,... WHERE 0)
is optimized out, however server tries to traverse this list.
