Added logging of all possible fatal table errors if --log-warnings set to > 1
mysql-test/extra/rpl_tests/rpl_EE_err.test:
Safety fix
mysql-test/extra/rpl_tests/rpl_row_basic.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/r/archive.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/r/csv.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/maria/r/maria-autozerofill.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/maria/t/maria-autozerofill.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/maria/t/maria-recover.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/parts/t/partition_recover_myisam.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_bug38694.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_idempotency.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_ignore_table.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_row_basic_11bugs.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_row_conflicts.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/r/rpl_temporary_errors.result:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_bug38694.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_idempotency.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_ignore_table.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_row_basic_11bugs.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_row_conflicts.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/suite/rpl/t/rpl_temporary_errors.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/t/archive.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
mysql-test/t/csv.test:
Added suppression of possible error message (so that one can run test with --log-warnings=2)
sql/handler.cc:
If running with --assert-of-crashed-table or --log-warnings > 1 then print engine error to log
sql/sql_select.cc:
Disable not initialized warning from gcc
strings/Makefile.am:
Fixed compiler error on Solaris 10 (duplicate strmov() function)
Analysis:
Close to its end JOIN::optimize() assigns having to tmp_having, and
sets the having clause to NULL:
tmp_having= having;
if (select_options & SELECT_DESCRIBE)
{
error= 0;
DBUG_RETURN(0);
}
having= 0;
At the same time, this query detects an empty result set, and calls
return_zero_rows(), which checks the HAVING clause as follows:
if (having && having->val_int() == 0)
send_row=0;
However having has been already set to NULL, so return_zero_rows
doesn't check the having clause, hence the wrong result.
Solution:
Check join->tmp_having in addition to join->having.
There is no additional test case, because the failure was in
the current regression test.
Aria and MyISAM in create_internal_tmp_table_from_heap()
(safe, as duplicates are impossible).
This gives a HUGE speed boost!
sql/opt_subselect.cc:
Fixed problem with wrong recinfo in create_duplicate_weedout_tmp_tabl()
Tagged the table with 'no_rows' so that when we create the table on disk,
we only store the index data. This gave us a major speedup!
sql/sql_select.cc:
create_tmp_table_from_heap() now uses bulk_insert + repair_by_sort
when creating Aria/MyISAM tables from HEAP tables.
This gives a HUGE speed boost!
storage/maria/ha_maria.cc:
Extended bulk_insert() to recreate UNIQUE keys for
internal temporary tables
storage/maria/ma_open.c:
Initialize m_info->lock.type properly for temporarly tables
(needed for start_bulk_insert())
storage/maria/ma_write.c:
Don't check uniques that are disabled
storage/myisam/ha_myisam.cc:
Extended bulk_insert() to recreate UNIQUE keys for
internal temporary tables.
This will also enable us in the future to collect statistics for
writes to internal tmp tables.
sql/handler.h:
Added ha_write_tmp_row()
sql/opt_subselect.cc:
ha_write_row -> ha_write_tmp_row
sql/sql_class.h:
Added ha_write_tmp_row()
sql/sql_select.cc:
ha_write_row -> ha_write_tmp_row
This makes the keys smaller (no row pointer) and gives us proper errors if we
use the table wrongly.
sql/sql_select.cc:
Use NO_RECORD for tables that doesn't need row data.
storage/maria/Makefile.am:
Added ma_norec.c
storage/maria/ma_check.c:
Added support for NO_RECORD record format (don't store any row data)
storage/maria/ma_norec.c:
Added support for NO_RECORD record format
storage/maria/ma_open.c:
Added support for NO_RECORD record format
storage/maria/ma_search.c:
Added support for 0 size row pointers (used with NO_RECORD)
storage/maria/ma_test1.c:
Added testing of NO_RECORD record format.
storage/maria/maria_chk.c:
Added support for NO_RECORD
storage/maria/maria_def.h:
Added support for NO_RECORD
storage/maria/unittest/ma_test_all-t:
Added testing of NO_RECORD record format
Made sure that the optimal fields are used by TABLE_REF objects
when building index access keys to joined tables.
Fixed a bug in the template function that sorts the elements of
a list using the bubble sort algorithm. The bug caused poor
performance of the function. Also added an optimization that
skips comparison with the most heavy elements that has been
already properly placed in the list.
Made the comparison of the fields belonging to the same Item_equal
more granular: fields belonging to the same table are also ordered
according to some rules.
An assertion failure was triggered for a 6-way join query that uses two
join buffers.
The failure happened because every call of the function flush_cached_records()
saved and restored status of all tables before the table join_tab. It
must do it only for those of them that follow the last table that uses
a join buffer.
Date: Mon, 01 Nov 2010 15:15:25 -0000
3272 Roy Lyseng 2010-11-01
Bug#52068: Optimizer generates invalid semijoin materialization plan
When MaterializeScan semijoin strategy was used and there were one
or more outer dependent tables before the semijoin tables, the scan
over the materialized table was not properly reset for each row of
the prefix outer tables.
Example: suppose we have a join order:
ot1 SJ-Mat-Scan(it2 it3) ot4
Notice that this is called a MaterializeScan, even though there is an
outer table ahead of the materialized tables. Usually a MaterializeScan
has the outer tables after the materialized table, but this is
a special (but legal) case with outer dependent tables both before and
after the materialized table.
For each qualifying row from ot1, a new scan over the materialized
table must be set up. The code failed to do that, so all scans after
the first one returned zero rows from the materialized table.
tmptable needed
The function DEFAULT() works by modifying the the data buffer pointers (often
referred to as 'record' or 'table record') of its argument. This modification
is done during name resolution (fix_fields().) Unfortunately, the same
modification is done when creating a temporary table, because default values
need to propagate to the new table.
Fixed by skipping the pointer modification for fields that are arguments to
the DEFAULT function.
in combination with IS NULL'
As this bug is a duplicate of bug#49322, it also includes test cases
covering this bugreport
Qualifying an OUTER JOIN with the condition 'WHERE <column> IS NULL',
where <column> is declared as 'NOT NULL' causes the
'not_exists_optimize' to be enabled by the optimizer.
In evaluate_join_record() the 'not_exists_optimize' caused
'NESTED_LOOP_NO_MORE_ROWS' to be returned immediately
when a matching row was found.
However, as the 'not_exists_optimize' is derived from
'JOIN_TAB::select_cond', the usual rules for condition guards
also applies for 'not_exist_optimize'. It is therefore incorrect
to check 'not_exists_optimize' without ensuring that all guards
protecting it is 'open'.
This fix uses the fact that 'not_exists_optimize' is derived from
a 'is_null' predicate term in 'tab->select_cond'. Furthermore,
'is_null' will evaluate to 'false' for any 'non-null' rows
once all guards protecting the is_null is open.
We can use this knowledge as an implicit guard check for the
'not_exists_optimize' by moving 'if (...not_exists_optimize)'
inside the handling of 'select_cond==false'. It will then
not take effect before its guards are open.
We also add an assert which requires that a
'not_exists_optimize' always comes together with
a select_cond. (containing 'is_null').
to crash mysqld".
handler::pushed_cond was not always properly reset when table objects where
recycled via the table cache.
handler::pushed_cond is now set to NULL in handler::ha_reset(). This should
prevent pushed conditions from (incorrectly) re-apperaring in later queries.
Fixed incorrect checks in join_read_const_table() for when to
accept a non-existing, or empty const-row as a part of the const'ified
set of tables.
Intention of this test is to only accept NULL-rows if this table is outer joined
into the resultset. (In case of an inner-join we can conclude at this point that
resultset will be empty, end we want to return 'error' to signal this.)
Initially 'maybe_null' is set to the same value as 'outer_join' in
setup_table_map(), mysql_priv.h ~line 2424. Later simplify_joins() will
attemp to replace outer joins by inner join whenever possible. This
will cause 'outer_join' to be updated. However, 'maybe_null' is *not* updated
to reflect this rewrite as this field is used to currectly set the 'nullability'
property for the columns in the resultset.
We should therefore change join_read_const_table() to check the 'outer_join'
property instead of 'maybe_null', as this correctly reflect the nullability of
the *execution plan* (not *resultset*).
An incorrect 'table_map' containing both the table itself,
and possible any outer-refs if this was the last table in
the subquery, was presented to make_cond_for_table().
As a pushed condition is only able to refer column from the table
the condition is pushed to, nothing else than columns from the
table itself (tab->table->map) may be refered in the pushed condition
constructed by 'push_cond= make_cond_for_table()'.
Also fix a minor 'copy and paste' bug in a comment
inside make_cond_for_table().
No testcase is possible on mainbranch as the NDB engine is not available (yet)
on mysql >= 5.5
- Removed files specific to compiling on OS/2
- Removed files specific to SCO Unix packaging
- Removed "libmysqld/copyright", text is included in documentation
- Removed LaTeX headers for NDB Doxygen documentation
- Removed obsolete NDB files
- Removed "mkisofs" binaries
- Removed the "cvs2cl.pl" script
- Changed a few GPL texts to use "program" instead of "library"
in sql_select.cc
Follow-up patch. Add sanity check for quick select when it is
decided that it should be used.
sql/opt_range.h:
Add is_valid() to QUICK_SELECT*
sql/sql_select.cc:
Add sanity check for quick select when it is decided that it should be used.
make_join_select() in sql_select.cc
Caused by incorrect ASSERT introduced by BUG#58456. Quick selects
may have index == MAX_KEY if it merges indices.
sql/sql_select.cc:
Removed ASSERT. Quick selects may have index == MAX_KEY if it merges indices.
in opt_range.h
In this bug, there are two alternative access plans:
* Index merge range access
* Const ref access
best_access_path() decided that the ref access was preferrable,
but make_join_select() still decided to point
SQL_SELECT::quick to the index merge because the table had
type==JT_CONST which was not handled.
At the same time the table's ref.key still referred to the
index the ref access would use indicating that ref access
should be used. In this state, different parts of the
optimizer code have different perceptions of which access path
is in use (ref or range).
test_if_skip_sort_order() was called to check if the ref access
needed ordering, but test_if_skip_sort_order() got confused and
requested the index merge to return records in sorted order.
Index merge cannot do this, and fired an ASSERT.
The fix is to take join_tab->type==JT_CONST into concideration
when make_join_select() decides whether or not to use the
range access method.
mysql-test/r/join_outer_innodb.result:
Add test for BUG#58456
mysql-test/t/join_outer_innodb.test:
Add test for BUG#58456
