bugfix: garbage in PLUGIN_VAR_STR variables when INSTALL'ing a plugin
mysql-test/include/default_mysqld.cnf:
disable feedback plugin by default.
when enabled - tag is as a test run
Analysis:
The cause of the bug was the changed meaning of
subselect_partial_match_engine::has_covering_null_row.
Previously it meant that there is row with NULLs in
all nullable fields of the materialized subquery table.
Later it was changed to mean a row with NULLs in all
fields of this table.
At the same time there was a shortcut in
subselect_rowid_merge_engine::partial_match() that
detected a special case where:
- there is no match in any of the columns with NULLs, and
- there is no NULL-only row that covers all columns with
NULLs.
With the change in the meaning of has_covering_null_row,
the condition that detected this special case was incomplete.
This resulted in an incorrect FALSE, when the result was a
partial match.
Solution:
Expand the condition that detected the special case with the
correct test for the existence of a row with NULL values in
all columns that contain NULLs (a kind of parially covering
NULL-row).
of the 5.3 code line after a merge with 5.2 on 2010-10-28
in order not to allow the cost to access a joined table to be equal
to 0 ever.
Expanded data sets for many test cases to get the same execution plans
as before.
- convert_subq_to_jtbm() didn't check that subuqery optimization was successful. If it wasn't (in this
example because of @@max_join_size violation), it would proceed further and eventually crash when
trying to execute the un-optimized subquery.
- The problem was that JOIN::save/restore_query_plan() did not save/restore parts of
the query plan that are located inside SJ_MATERIALIZATION_INFO structures. This could
cause parts of one plan to be used with another, which led get_best_combination() to
constructing non-sensical join plans (and crash).
Fixed by saving/restoring SJM parts of the query plans.
- check_and_do_in_subquery_rewrites() will not set SUBS_MATERIALIZATION flag when it
records that the subquery predicate is to be converted into semi-join.
If convert_join_subqueries_to_semijoins() later decides not to convert to semi-join,
let it set SUBS_MATERIALIZATION flag, if appropriate.
- are_tables_local() failed to recognize the fact that OUTER_REF_TABLE_BIT is ok
for SJ-Materialization. This caused zero-length ref access to be constructed, which
led to an assert.
1 - If a user had SHOW VIEW and SELECT privileges on a view and
this view was referencing another view, EXPLAIN SELECT on the outer
view (that the user had privileges on) could reveal the structure
of the underlying "inner" view as well as the number of rows in
the underlying tables, even if the user had privileges on none of
these referenced objects.
This happened because we used DEFINER's UID ("SUID") not just for
the view given in EXPLAIN, but also when checking privileges on
the underlying views (where we should use the UID of the EXPLAIN's
INVOKER instead).
We no longer run the EXPLAIN SUID (with DEFINER's privileges).
This prevents a possible exploit and makes permissions more
orthogonal.
2 - EXPLAIN SELECT would reveal a view's structure even if the user
did not have SHOW VIEW privileges for that view, as long as they
had SELECT privilege on the underlying tables.
Instead of requiring both SHOW VIEW privilege on a view and SELECT
privilege on all underlying tables, we were checking for presence
of either of them.
We now explicitly require SHOW VIEW and SELECT privileges on
the view we run EXPLAIN SELECT on, as well as all its
underlying views. We also require SELECT on all relevant
tables.
mysql-test/r/view_grant.result:
add extensive tests to illustrate desired behavior and
prevent regressions (as always).
mysql-test/t/view_grant.test:
add extensive tests to illustrate desired behavior and
prevent regressions (as always).
sql/sql_view.cc:
We no longer run the EXPLAIN SUID (with DEFINER's privileges).
To achieve this, we use a temporary, SUID-less TABLE_LIST for
the views while checking privileges.
Analysis:
The crash is a result of the same cause as all similar
bugs (lp:827416, lp:718763, lp:778413, lp:806943,
lp:611690). The general pattern is that some optimization
requires the evaluation of some condition (e.g. the WHERE
clause), and this condition contains a subquery, such that
the subquery itself requires a temporary table for its
execution. During the subquery execution the original
tables in the FROM clause are replaced by the temporary
table needed for the final GROUP or ORDER operation. All
this happens during optimization of the outer query. Later
when EXPLAIN is run for the subquery, explain attempts to
print the name of the tables in the FROM clause, but it
finds there a temporary table without a corresponding
TABLE_LIST object. The attempt to print the name of a
NULL table list results in a crash.
Solution:
This patch extends the fix to bug lp:702301, and dissalows
constant substitution of aggregate functions if the filter
condition used to check MIN/MAX keys is an expensive condition.
CREATE_TIME IN INFORMATION_SC
It was impossible to determine MEMORY table creation time,
since it wasn't stored/exposed.
With this patch creation time is saved and it is available via
I_S.TABLES.CREATE_TIME.
Note: it was decided that additional analysis is required before
implementing UPDATE_TIME. Thus this patch doesn't store UPDATE_TIME.
Added 'innodb_file_format_check' as variable to ignore change to.
Tests that had to restore this amended
Two tests assumed it to be Antelope, make sure these run on a freshly
started server
For 5.5, apparently innodb_file_format_max is the one to ignore
One can set @@global.max_user_connections to -1 to block anyone, except SUPER user, to login.
If max_user_connection is 0, one can't change it without a restart (needed to get user connections counting to work correctly)
mysql-test/r/system_mysql_db.result:
Changed max_user_connections to handle negative numbers.
mysql-test/r/user_limits-2.result:
New test case that one can't change max_user_connection if it was 0
mysql-test/r/user_limits.result:
Fixed wrong error messages.
mysql-test/r/variables.result:
Store / restore max_user_connections (needed as there is now a --master.opt file that changes it)
mysql-test/t/subselect_mat_cost-master.opt:
Enable slow query log (as this test found some errors in slow query logging)
mysql-test/t/user_limits-2.test:
New test case that one can't change max_user_connection if it was 0
mysql-test/t/user_limits-master.opt:
Set max_user_connections (as one can't change it if it was 0)
mysql-test/t/user_limits.test:
Test max_user_connections -1
mysql-test/t/variables-master.opt:
Set max_user_connections (as one can't change it if it was 0)
mysql-test/t/variables.test:
Set/restore max_user_connections
scripts/Makefile.am:
Add a text message to mysql_fix_privilege_tables.sql that it's automaticly generated
scripts/mysql_system_tables.sql:
Change max_user_connections to signed
scripts/mysql_system_tables_fix.sql:
Change max_user_connections to signed
sql/item_func.cc:
Change SHOW_INT to be signed.
(Needed for max_user_connections and it's probably a bug that it was not originally signed)
sql/log.cc:
Remove some code that was not needed (All these variables are reset at start of query)
sql/mysql_priv.h:
Made max_user_connections signed.
Added max_user_connections_checking
sql/mysqld.cc:
Added max_user_connections_checking so that we know if max_user_connections was 0 at startup
(Which means that we will not do connection counting for accounts that don't have user resource limits)
Set thd->start_utime at same time as thr_create_utime. (Before start_utime could be < thr_create_utime which lead to wrong query counting)
sql/set_var.cc:
Don't allow one to change 'max_user_connections' if it was 0 at startup.
sql/sql_acl.cc:
Change user_connection counting to be negative.
sql/sql_connect.cc:
If max_user_connections is < 0 then only SUPER user can login.
Fixed wrong variable names for error messages.
Fixed wrong initial value for questions.
Set thd->start_utime and thd->thr_create_utime at startup. Needed to get time_out_user_resource_limits() to work.
sql/sql_show.cc:
SHOW_INT is now negative
sql/sql_yacc.yy:
Support negative values for MAX_USER_CONNECTIONS
sql/structs.h:
Make user connect counting work with signed numbers.
Line autointersection point was treated as if it doesn't belong to the line.
It's in some way logical, but seems to confuse people. Fixed.
per_file_comments:
mysql-test/r/gis-precise.result
bug 857087 Wrong result with ST_INTERSECTS and LINESTRINGs
test result updated.
mysql-test/t/gis-precise.test
bug 857087 Wrong result with ST_INTERSECTS and LINESTRINGs
test case added.
sql/gcalc_tools.cc
bug 857087 Wrong result with ST_INTERSECTS and LINESTRINGs
Point of line autointersection handled as it belongs to the line.
sql/gcalc_tools.h
bug 857087 Wrong result with ST_INTERSECTS and LINESTRINGs
Gcalc_function::set_i_state() added
Reset 'examined_rows_count' in union to not count same rows twice
mysql-test/r/subselect_mat_cost.result:
Test also slow query logging
mysql-test/t/subselect_mat_cost.test:
Test also slow query logging
sql/sql_union.cc:
Reset 'examined_rows_count' in union to not count same rows twice
actually only testcase added as the bug was fixed already.
modified:
mysql-test/r/gis-precise.result
bug #857050 ST_WITHIN returns wrong result with MULTIPOINT and POLYGON
test result updated.
mysql-test/t/gis-precise.test
bug #857050 ST_WITHIN returns wrong result with MULTIPOINT and POLYGON
test case added.
sql/gcalc_tools.cc
superfluous variable removed.
The 'single point' event was forgotten in the relation's calculation
per-file comments:
mysql-test/r/gis-precise.result
fix for bug 857051 ST_EQUALS returns TRUE on two nonidentical MULTIPOINTs
test result updated.
mysql-test/t/gis-precise.test
fix for bug 857051 ST_EQUALS returns TRUE on two nonidentical MULTIPOINTs
test case added.
sql/gcalc_tools.cc
fix for bug 857051 ST_EQUALS returns TRUE on two nonidentical MULTIPOINTs
scev_single_point is properly handled.
- If USER is given, all threads for that user is signaled
- If SOFT is used then the KILL will not be sent to the handler. This can be used to not interrupt critical things in the handler like 'REPAIR'.
Internally added more kill signals. This gives us more information of why a query/connection was killed.
- KILL_SERVER is used when server is going down. In this case the users gets ER_SHUTDOWN as the reason connection was killed.
- Changed signals to number in correct order, which makes it easier to test how the signal should affect the code.
- New error message ER_CONNECTION_KILLED if connection was killed by 'KILL CONNECTION'. Before we got error ER_SHUTDOWN.
Changed names of not used parameters KILL_QUERY & KILL_CONNCTION to mysql_kill() to not conflict with defines in the server
include/mysql.h.pp:
Updated file
include/mysql_com.h:
Changed names of not used parameters KILL_QUERY & KILL_CONNCTION to mysql_kill() to not conflict with defines in the server
mysql-test/r/kill.result:
Added test of KILL USER
mysql-test/suite/rpl/r/rpl_stm_000001.result:
Updated error code
mysql-test/suite/rpl/t/rpl_stm_000001.test:
Updated error codes
mysql-test/t/flush_read_lock_kill.test:
Updated error codes
mysql-test/t/kill.test:
Added test of KILL USER
plugin/handler_socket/handlersocket/database.cpp:
Removed THD:: from KILL
sql/debug_sync.cc:
Removed THD:: from KILL
sql/event_scheduler.cc:
Removed THD:: from KILL
sql/filesort.cc:
Removed THD:: from KILL
sql/ha_ndbcluster_binlog.cc:
Removed THD:: from KILL
sql/handler.cc:
Removed THD:: from KILL
Simplify code.
sql/lex.h:
Added new keywords HARD | SOFT
sql/log.cc:
Removed THD:: from KILL
Added testing of new error ER_CONNECTION_KILLED
sql/log_event.cc:
Removed THD:: from KILL
Added testing of new error ER_CONNECTION_KILLED
sql/mysql_priv.h:
Added new prototypes
sql/mysqld.cc:
Removed THD:: from KILL
Use KILL_SERVER_HARD signal on shutdown.
sql/scheduler.cc:
Removed THD:: from KILL
Simplify test if connection should be killed
sql/share/errmsg.txt:
New error message ER_CONNECTION_KILLED
sql/slave.cc:
Removed THD:: from KILL
sql/sp_head.cc:
Removed THD:: from KILL
sql/sql_base.cc:
Removed THD:: from KILL
sql/sql_cache.cc:
Removed THD:: from KILL
sql/sql_class.cc:
Removed THD:: from KILL
Added killed_errno()
Only signal kill to storage engine if HARD bit is set.
sql/sql_class.h:
Move KILL options out from THD to make them easier to use in sql_yacc.yy
sql/sql_connect.cc:
Removed THD:: from KILL
sql/sql_delete.cc:
Removed THD:: from KILL
sql/sql_error.cc:
Removed THD:: from KILL
sql/sql_insert.cc:
Removed THD:: from KILL
Simplifed testing if thread is killed.
sql/sql_lex.h:
Added kill options to st_lex
sql/sql_load.cc:
Removed THD:: from KILL
sql/sql_parse.cc:
Added kill options to st_lex
Simplifed and optimzed testing of thd->killed at end of query
Added support for KILL USER
Extended sql_kill() to allow use of more kill signals.
sql/sql_repl.cc:
Removed THD:: from KILL
sql/sql_show.cc:
Removed THD:: from KILL
Simplied testing if query/connection was killed
sql/sql_table.cc:
Removed THD:: from KILL
sql/sql_update.cc:
Removed THD:: from KILL
sql/sql_yacc.yy:
Added support for new KILL syntax: KILL [HARD|SOFT] [CONNECTION|QUERY] [ID | USER user_name]
storage/archive/ha_archive.cc:
Simplify compilation
storage/maria/ha_maria.cc:
Removed THD:: from KILL
- Provide fix_after_pullout() function for Item_in_optimizer and other Item_XXX classes (basically, all of them
that have eval_not_null_tables, which means they have special rules for calculating not_null_tables_cache value)
855485 ST_CROSSES returns different result than PostGIS for overlapping polygons
855487 ST_WITHIN returns wrong result for partially overlapping polygons
855492 ST_WITHIN returns TRUE on point on the edge of a polygon
855497 ST_ENVELOPE of GEOMETRYCOLLECTION EMPTY returns NULL and not GEOMETRYCOLLECTION EMPTY
855503 ST_EQUALS reports TRUE between a POLYGON and a MULTILINESTRING
855505 ST_TOUCHES reports TRUE for intersecting polygon and linestring
Changed the way weird functions like Crosses or Touches treated.
Added BORDER handling to the Gcalc_function.
per-file comments:
mysql-test/r/gis-precise.result
GIS bugs fixed.
test result updated.
mysql-test/t/gis-precise.test
GIS bugs fixed.
test cases added.
sql/gcalc_slicescan.h
GIS bugs fixed.
sql/gcalc_tools.cc
GIS bugs fixed.
sql/gcalc_tools.h
GIS bugs fixed.
sql/item_create.cc
GIS bugs fixed.
sql/item_geofunc.cc
GIS bugs fixed.
sql/item_geofunc.h
GIS bugs fixed.
sql/spatial.cc
GIS bugs fixed.
per-file comments:
mysql-test/r/gis.result
bug 855336 ST_LENGTH does not work on GEOMETRYCOLLECTIONs fixed.
test result updated.
mysql-test/t/gis.test
bug 855336 ST_LENGTH does not work on GEOMETRYCOLLECTIONs fixed.
test case added.
sql/item_geofunc.cc
bug 855336 ST_LENGTH does not work on GEOMETRYCOLLECTIONs fixed.
geom_length() call fixed.
sql/spatial.cc
bug 855336 ST_LENGTH does not work on GEOMETRYCOLLECTIONs fixed.
Geometry_collection::geom_length implemented.
sql/spatial.h
bug 855336 ST_LENGTH does not work on GEOMETRYCOLLECTIONs fixed.
Geometry_collection::geom_length declaration added.
855253 Compiler error: gcalc_slicescan.cc:2036: error: suggest parentheses around comparison in operand of .|. in maria-5.3-gis
850775 ST_AREA does not work on GEOMETRYCOLLECTIONs in maria-5.3-gis
per-file comments:
mysql-test/r/gis.result
test result updated.
mysql-test/t/gis.test
test case added for 850775.
sql/gcalc_slicescan.cc
compiler error fixed.
sql/spatial.cc
ST_AREA implementation for GEOMETRY_COLLECTION, POINT and LINESTRING.
sql/spatial.h
area() declarations added.
- The problem was that Item_direct_view_ref and its embedded Item_field were getting incorrect
value of item->used_tables() after fix_fields() in the second and subsequent EXECUTE.
- Made relevant fixes in Item_field::fix_fields() and find_field_in_tables(), so that the
Item_field gets the correct attributes.
- If convert_join_subqueries_to_semijoins() decides to wrap Item_in_subselect in Item_in_optimizer,
it should do so in prep_on_expr/prep_where, too, as long as they are present.
There seems to be two possibilities of how we arrive in this function:
- prep_on_expr/prep_where==NULL, and will be set later by simplify_joins()
- prep_on_expr/prep_where!=NULL, and it is a copy_and_or_structure()-made copy of on_expr/where.
the latter can happen for some (but not all!) nested joins. This bug was that we didn't handle this case.
FULLTEXT INDEXES
myisamchk may create incorrect fulltext index for compressed
tables. Incorrect data pointer size was used while creating
fulltext index.
mysql-test/r/myisampack.result:
A test case for BUG#11761180.
mysql-test/t/myisampack.test:
A test case for BUG#11761180.
storage/myisam/ft_boolean_search.c:
rec_reflength on share may have adjustments required for
compressed tables and must be used instead of rec_reflength
on base info.
storage/myisam/ft_nlq_search.c:
rec_reflength on share may have adjustments required for
compressed tables and must be used instead of rec_reflength
on base info.
storage/myisam/mi_check.c:
rec_reflength on share may have adjustments required for
compressed tables and must be used instead of rec_reflength
on base info.
storage/myisam/mi_write.c:
rec_reflength on share may have adjustments required for
compressed tables and must be used instead of rec_reflength
on base info.
Call handle_error() instead of die() when evaluating these
Must remember "current command" with link to errors to ignore
Added test cases to mysqltest.test
- Mrr_ordered_index_reader::interrupt_read() and resume_read() should
save/restore not just index lookup tuple, but entire index tuple.
Key parts that are not used for index lookup can be still used in
pushed index condition. Failure to save/restore will cause the index
condition to be evaluated over the wrong values.
Give proper error to client on shutdown.
configure.in:
Increased version number
mysql-test/mysql-test-run.pl:
Ignore errors that one can get while running with --mysqld=--log-warnings=2
mysql-test/r/variables.result:
Remember original value of log_warnings
mysql-test/suite/rpl/r/rpl_idempotency.result:
Ignore errors that one can get while running with --mysqld=--log-warnings=2
mysql-test/suite/rpl/t/rpl_idempotency.test:
Ignore errors that one can get while running with --mysqld=--log-warnings=2
mysql-test/t/variables.test:
Remember original value of log_warnings
sql/mysqld.cc:
Give proper error to close_connection() on shutdown
storage/maria/ha_maria.cc:
Added missing DBUG_RETURN
Coordinates were mistakenly reversed for MULTIPOINT.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug 848939 Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis
test result updated.
mysql-test/t/gis-precise.test
Fix for bug 848939 Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis
test case added.
sql/gcalc_tools.cc
Fix for bug 848939 Wrong result with ST_INTERSECTION between linestrings and a polygon in 5.3-gis
coordinates set in the proper order.
That assertion's check was too tight. Released it a bit.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #848901
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #848901
test case added.
sql/gcalc_slicescan.cc
Fix for bug #848901
The DBUG_ASSERT check is too tight here.
#841622 Assertion `t->rp->type == Gcalc_function::shape_line' failed in Gcalc_operation_reducer::end_line in maria-5.3-gi
#841625 Assertion `m_poly_borders->next' failed in Gcalc_operation_reducer::count_slice in maria-5.3-gis
#841638 Assertion `!m_prev || m_prev->x != x || m_prev->y != y' failed in Gcalc_shape_transporter::int_add_point in maria-5.3-gis
#841662 Third assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos
#841745 Assertion `!sp0->is_bottom()' failed in Gcalc_scan_iterator::find_intersections in maria-5.3-gis
They mostly was caused by inprecision of double arithmetic.
Fixed by changes in how to handle multiple intersections to keep their order right.
Also ST_DISTANCE(GEOM, EMPTY_GEOM) was defined as NULL.
per-file comments:
mysql-test/r/gis-precise.result
GIS bugfixes.
test result updated.
mysql-test/t/gis-precise.test
GIS bugfixes.
test cases added.
sql/gcalc_slicescan.cc
GIS bugfixes.
If intersections are close, add order checks to cope with the
double calcualtions imprecision.
sql/gcalc_slicescan.h
GIS bugfixes.
n_row parameter added to intersection to check their order.
sql/item_geofunc.cc
GIS bugfixes.
ST_DISTANCE(GEOM, EMPTY_GEOM) returns NULL.
- The bug was caused by outer join being incorrectly converted into inner because of
invalid return values of Item_direct_view_ref::not_null_tables().
- Provided a correct Item_direct_view_ref::not_null_tables() function.
- Let join buffering code correctly take into account rowids needed
by DuplicateElimination when it is calculating minimum record sizes.
- In JOIN_CACHE::write_record_data, added asserts that prevent us from
writing beyond the end of the buffer.
The problem was that optimization code did not take into account later feature when instad of NOT before BETWEEN it has negated flag into the Item_func_between inherited from Item_func_neg_opt. So optimizer tried process NOT BETWEEN as BETWEEN.
The patch just switches off the optimisation for NOT BETWEEN as it was before when NOT function was really used.
For any query JOIN::optimize() should call the method
SELECT::save_leaf_tables after the last transformation
that utilizes the statement memory rather than the
execution memory.
ALL subquery should return TRUE if subquery rowa set is empty independently
of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not
call execution of second argument if first is NULL no in this case subquery
will not be executed and when Item_func_not_all calls any_value() of the
subquery or aggregation function which report that there was rows. So for
NULL < ALL (SELECT...) result was FALSE instead of TRUE.
Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with
changing the operation if it is needed) so that result will be the same
(for examole a < b is equal to b > a). This fix exploit the fact that
first argument will be executed in any case.
When edges of a polygon coicide, it can form an pike, that is turned into a line after an operation.
In this case a former polygon point can be an end of a single line, and that case wasn't properly handled.
per-file comments:
mysql-test/r/gis-precise.result
bug 839327 Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.
test result updated.
mysql-test/t/gis-precise.test
bug 839327 Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.
test case added.
sql/gcalc_tools.cc
bug 839327 Crash in Gcalc_operation_reducer::end_couple with ST_UNION and MULTIPOLYGONs in 5.3-gis.
in the scev_two_ends case check if we have single line ending on a polygon node.
wrong variable was used as a result of inattentive copypaste.
per-file comments:
mysql-test/r/gis-precise.result
bug 839318 Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.
test result updated.
mysql-test/t/gis-precise.test
bug 839318 Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.
test case added.
sql/item_geofunc.cc
bug 839318 Crash in Gcalc_scan_iterator::point::get_shape with ST_DISTANCE and MULTILINESTRING in maria-5.3-gis.
use 'ev' variable instead of the 'evpos'.
Line loops weren't recognized when collect results.
Fixed by checking if we got the same beginning point of the line.
per-file comments:
mysql-test/r/gis-precise.result
bug 839341 100% CPU usage with ST_UNION in maria-5.3-gis.
test result updated.
mysql-test/t/gis-precise.test
bug 839341 100% CPU usage with ST_UNION in maria-5.3-gis.
test case added.
sql/gcalc_tools.cc
bug 839341 100% CPU usage with ST_UNION in maria-5.3-gis.
check if we get the beginning node of the linestring, then cut the loop.
We didn't implement an empty geometry. And returning NULL instead of it is not
quite correct. So here is the implementation of the empty value as GEOMETRYCOLLECTION().
per-file comments:
mysql-test/r/gis-precise.result
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
test result updated.
mysql-test/r/gis.result
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
test result updated.
mysql-test/t/gis-precise.test
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
test case added.
mysql-test/t/gis.test
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
test case added.
sql/field.cc
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
store GEOMETRYCOLLECTION() properly.
sql/gcalc_tools.cc
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
create the GEOMETRYCOLLECTION() for the empty result.
sql/gstream.h
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
next_symbol() added.
sql/spatial.cc
bug 801466 ST_INTERSECTION() returns invalid value on empty intersection in maria-5.3-gis.
code modified to handle 0 geometries in the GEOMETRYCOLLECTION properly.
- Item_in_subselect::inject_in_to_exists_cond() should not call
((Item_cond*)join->conds)->argument_list()->concat(join->cond_equal->current_level)
as that makes two lists share their tail, and the cond_equal list
will end up containing non-Item_equal objects when substitute_for_best_equal_field()
walks through join->conds and replaces all Item_equal objects with Item_func_eq objects.
- So, instead of using List::concat(), manually copy entries from one list to another.
- setup_sj_materialization() code failed to take into account that it can be that
the first [in join order ordering] table inside semi-join-materialization nest
is also an inner table wrt an outer join (that is embedded in the semi-join).
This can happen when all of the tables that are inside the semi-join but not inside
the outer join are constant.
- Made a trivial to not assume that table's embedding join nest is the semi-join
nest: instead, walk up the outer join nests until we reach the semi-join nest.
For ANY subqueries NULLs should be ignored (if there is other values) when finding max min.
For ALL subqueries NULLs should be saved if they found.
Optimisation for ALL suqbueries if NULL is possible in the SELECT list with max/min aggregate function switched off.
Some test changed where NULL is not used but optimization with max/min aggregate function important so NOT NULL added.
mysql-test/r/explain.result:
Forced old optimization.
mysql-test/r/subselect.result:
Forced old optimization.
New test suite.
mysql-test/t/explain.test:
Forced old optimization.
mysql-test/t/subselect.test:
Forced old optimization.
New test suite.
sql/item_subselect.cc:
Store converted subquery type.
Switch off aggregate function optimisation for ALL and nulls.
sql/sql_class.cc:
Fixed NULL comparison.
sql/sql_class.h:
Store converted subquery type.
tests added.
per-file comments:
mysql-test/r/gis-precise.result
bugs #801560 and #802194
test result updated.
mysql-test/t/gis-precise.test
bugs #801560 and #802194
test case added.
Analysis:
In the test query semi-join merges the inner-most subquery
into the outer subquery, and the optimization of the merged
subquery finds some new index access methods. Later the
IN-EXISTS transformation is applied to the unmerged subquery.
Since the optimizer is instructed to not consider
materialization, it reoptimizes the plan in-place to take into
account the new IN-EXISTS conditions. Just before reoptimization
JOIN::choose_subquery_plan resets the query plan, which also
resets the access methods found during the semi-join merge.
Then reoptimization discovers there are no new access methods,
but it leaves the query plan in its reset state. Later semi-join
crashes because it assumes these access methods are present.
Solution:
When reoptimizing in-place, reset the query plan only after new
access methods were discovered. If no new access methods were
discovered, leave the current plan as it was.
GROUPING BY FUNCTIONS.... (PART
The bug was introduced in a patch for bug 49897.
Problem: The assertion inserted by the original patch to guard against
zero-lenght sort keys during merge phase triggers also when the whole
set fits in memory.
Fix: Move assert so that it does not trigger if the whole set is in
memory.
mysql-test/r/group_by.result:
Add test for bug#11765254
mysql-test/t/group_by.test:
Add test for bug#11765254
sql/filesort.cc:
Move assertion
- The problem was that the code that made the check whether the subquery is an AND-part of the WHERE
clause didn't work correctly for nested subqueries. In particular, grand-child subquery in HAVING was
treated as if it was in the WHERE, which eventually caused an assert when replace_where_subcondition
looked for the subquery predicate in the WHERE and couldn't find it there.
- The fix: Removed implementation of "thd_marker approach". thd->thd_marker was used to determine the
location of subquery predicate: setup_conds() would set accordingly it when making the
{where|on_expr}->fix_fields(...)
call so that AND-parts of the WHERE/ON clauses can determine they are the AND-parts.
Item_cond_or::fix_fields(), Item_func::fix_fields(), Item_subselect::fix_fields (this one was missed),
and all other items-that-contain-items had to reset thd->thd_marker before calling fix_fields() for
their children items, so that the children can see they are not AND-parts of WHERE/ON.
- The "thd_marker approach" required that a lot of code in different locations maintains correct value of
thd->thd_marker, so it was replaced with:
- The new approach with mark_as_condition_AND_part does not keep context in thd->thd_marker. Instead,
setup_conds() now calls
{where|on_expr}->mark_as_condition_AND_part()
and implementations of that function make sure that:
- parts of AND-expressions get the mark_as_condition_AND_part() call
- Item_in_subselect objects record that they are AND-parts of WHERE/ON
Converting the number zero to binary and back yielded the number zero,
but with no digits, i.e. zero precision.
This made the multiply algorithm go haywire in various ways.
include/decimal.h:
Document struct st_decimal_t
mysql-test/r/type_newdecimal.result:
New test case (valgrind warnings)
mysql-test/t/type_newdecimal.test:
New test case (valgrind warnings)
sql/my_decimal.h:
Remove the HAVE_purify enabled/disabled code.
strings/decimal.c:
Make a proper zero, with non-zero precision.
Analysis:
Constant table optimization of the outer query finds that
the right side of the equality is a constant that can
be used for an eq_ref access to fetch one row from t1,
and substitute t1 with a constant. Thus constant optimization
triggers evaluation of the subquery during the optimize
phase of the outer query.
The innermost subquery requires a plan with a temporary
table because with InnoDB tables the exact count of rows
is not known, and the empty tables cannot be optimzied
way. JOIN::exec for the innermost subquery substitutes
the subquery tables with a temporary table.
When EXPLAIN gets to print the tables in the innermost
subquery, EXPLAIN needs to print the name of each table
through the corresponding TABLE_LIST object. However,
the temporary table created during execution doesn't
have a corresponding TABLE_LIST, so we get a null
pointer exception.
Solution:
The solution is to forbid using expensive constant
expressions for eq_ref access for contant table
optimization. Notice that eq_ref with a subquery
providing the value is still possible during regular
execution.
PARTITONING, ON INDEX CREATE
If the first partition succeeded in adding a index, but a successive partition failed,
then the first partition had still the new index.
The fix reverts the added indexes from previous partitions on failure.
Analysis:
During the first execution of the query through the stored
procedure, the optimization phase calls
substitute_for_best_equal_field(), which calls
Item_in_optimizer::transform(). The latter replaces
Item_in_subselect::left_expr with args[0] via assignment.
In this test case args[0] is an Item_outer_ref which is
created/deallocated for each re-execution. As a result,
during the second execution Item_in_subselect::left_expr
pointed to freed memory, which resulted in a crash.
Solution:
The solution is to use change_item_tree(), so that the
origianal left expression is restored after each execution.
Analysis:
Partial matching is used even when there are no NULLs in
a materialized subquery, as long as the left NOT IN operand
may contain NULL values.
This case was not handled correctly in two different places.
First, the implementation of parital matching did not clear
the set of matching columns when the merge process advanced
to the next row.
Second, there is no need to perform partial matching at all
when the left operand has no NULLs.
Solution:
First fix subselect_rowid_merge_engine::partial_match() to
properly cleanup the bitmap of matching keys when advancing
to the next row.
Second, change subselect_partial_match_engine::exec() so
that when the materialized subquery doesn't contain any
NULLs, and the left operand of [NOT] IN doesn't contain
NULLs either, the method returns without doing any
unnecessary partial matching. The correct result in this
case is in Item::in_value.
When the WHERE/HAVING condition of a subquery has been transformed
by the optimizer the pointer stored the 'where'/'having' field
of the SELECT_LEX structure used for the subquery must be updated
accordingly. Otherwise the pointer may refer to an invalid item.
This can lead to the reported assertion failure for some queries
with correlated subqueries
CRASHES SERVER
Flushing of MERGE table or one of its child tables, which was
locked by flushing thread using LOCK TABLES, might have caused
crashes or assertion failures if the thread failed to reopen
child or parent table.
Particularly, this might have happened when another connection
killed this FLUSH TABLE statement/connection.
Also this problem might have occurred when we failed to reopen
MERGE table or one of its children when executing DDL statement
under LOCK TABLES.
The problem was caused by the fact that reopen_tables() might
have failed to reopen child table but still tried to reopen,
reattach children for and re-lock its parent. Vice versa it
might have failed to reopen parent but kept references from
children to parent around. Since reopen_tables() closes table
it has failed to reopen and therefore frees all associated
memory such dangling references led to crashes when followed.
This patch solves this problem by ensuring that we always close
parent table and all its children if we fail to reopen this
table or one of its children. Same happens if we fail to reattach
children to parent.
Affects 5.1 only.
mysql-test/r/merge.result:
A test case for BUG#11763712.
mysql-test/t/merge.test:
A test case for BUG#11763712.
sql/sql_base.cc:
When flushing tables under LOCK TABLES, all locked
and flushed tables are released and then reopened.
It may happen that we failed to reopen some tables,
in this case we reopen as much tables as possible.
If it was not possible to reopen MERGE child, MERGE
parent is unusable and must be removed from thread
open tables list.
If it was not possible to reopen MERGE parent, all
MERGE child table objects are unusable as well, at
least because their locks are handled by MERGE parent.
They must also be removed from thread open tables
list.
In other words if it was impossible to reopen any
object of a MERGE table or reattach child tables,
all objects of this MERGE table must be considered
unusable and closed.
The bug is a duplicate of MySQL's Bug#11764086,
however MySQL's fix is incomplete for MariaDB, so
this fix is slightly different.
In addition, this patch renames
Item_func_not_all::top_level() to is_top_level_item()
to make it in line with the analogous methods of
Item_in_optimizer, and Item_subselect.
Analysis:
It is possible to determine whether a predicate is
NULL-rejecting only if it is a top-level one. However,
this was not taken into account for Item_in_optimizer.
As a result, a NOT IN predicate was erroneously
considered as NULL-rejecting, and the NULL-complemented
rows generated by the outer join were rejected before
being checked by the NOT IN predicate.
Solution:
Change Item_in_optimizer to be considered as
NULL-rejecting only if it a top-level predicate.
- add_ref_to_table_cond() should not just overwrite pre_idx_push_select_cond
with the contents tab->select_cond.
pre_idx_push_select_cond exists precisely for the reason that it may contain
a condition that is a strict superset of what is in tab->select_cond.
The fix is to inject generated equality into pre_idx_push_select_cond.
- Make simplify_joins() set maybe_null=FALSE for tables that were on the
inner sides of inner joins and then were moved to the inner sides of semi-joins.
When merging a view / derived table the function SELECT_LEX::merge_subquery
incorrectly updated the list SELECT_LEX::leaf_tables. Erroneously it
appended the leaf_tables list of the merged object L and then removed the
reference to the merged object T from the SELECT_LEX::leaf_tables list.
A correct implementation should insert the list L into the
SELECT_LEX::leaf_tables list in place of the element of the list that
refers to T.
The bug could lead to wrong results or even crashes for queries with
nested outer joins over views / derived tables.
Identified all test cases in the MySQL file subquery.inc that are
not present in MariaDB. This patch adds the test cases that are:
- not present in MySQL 5.5, and
- already fixed in MariaDB 5.3
The patch adds test cases for the following mysql-trunk bugs:
- Bug#12763207 - not a bug, mysql-trunk, added test case
- BUG#50257 - not a bug, mysql-trunk, added test case
- Bug 11765699 - not a bug, mysql-trunk, added test case
- BUG#12616253 - not a bug, mysql-trunk, added test case
The comparison was based on the following version of
mysql-trunk:
revno: 3350 [merge]
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: mysql-trunk
timestamp: Mon 2011-08-08 12:42:09 +0300
message:
Merge mysql-5.5 to mysql-trunk.
The method Item_ref::not_null_tables() returned incorrect bitmap
for outer references to view columns. This could cause an invalid
conversion of an outer join into an inner join that could lead
to a wrong result set for a query with a correlated subquery over
an outer join whose where condition had an outer reference to a view.
The method Item_func_isnull::update_used_tables() erroneously did not
update cached values stored in the fields used_tables_cache and
const_item_cache of the Item_func_isnull objects. As a result the
Item_func_isnull::used_tables() returned wrong bitmaps and, as a
consequence, push-down predicates could be attached to wrong tables.
This fixes a bug that when you use mysqldump --no-create-info to generate a dump that you want to merge with an existing table,
you can get an innodb table with duplicated unique keys.
Patch orignally by Eric Bergen.
client/mysqldump.c:
Only use UNIQUE_CHECKS=0 for tables that are created.
This solves the issue that you can't get duplicate unique keys when merging two dumps.
mysql-test/r/mysqldump.result:
Test for mysqldump --no-create-info
Identified all test cases in the MySQL file subquery_mat.inc that are
not present in MariaDB. In total found 8 test cases for the following
MySQL bugs:
* BUG#49630 - not a bug in MariaDB, added test case
* BUG#52538 - not a bug in MariaDB, added test case (checked with VG)
* BUG#53103 - not a bug in MariaDB, added test case
* BUG#54511 - not a bug in MariaDB, added test case
* BUG#56367 - not a bug in MariaDB, added test case
* BUG#59833 - not a bug in MariaDB, added test case
* BUG#11852644 - not a bug in MariaDB, added test case
* BUG#12668294 - not a bug in MariaDB, added test case
All of these MySQL bugs are not present in MariaDB 5.3.
The comparison was based on the following version of
mysql-trunk:
revno: 3350 [merge]
committer: Marko Mäkelä <marko.makela@oracle.com>
branch nick: mysql-trunk
timestamp: Mon 2011-08-08 12:42:09 +0300
message:
Merge mysql-5.5 to mysql-trunk.
This bug is a special case of lp:813447.
Analysis:
Constant optimization finds that the condition t2.a = 1
can be used to access the primary key of table 't2'. As
a result both outer table t1,t2 are considered as constant
when we reach the execution phase. At the same time, during
constant optimization, the IN predicate is not evaluated
because it is expensive.
When execution of the outer query reaches do_select(),
control flow enter the branch:
if (join->table_count == join->const_tables)
{ ... }
This branch checks only the WHERE and HAVING clauses,
but doesn't check the ON clauses of the query. Since the
IN predicate was not evaluated during optimization, it is
not evaluated at all, thus execution doesn't detect that
the ON clause is FALSE.
Solution:
Similar to the patch for bug lp:813447, exclude system
tables from constant substitution based on unique key
lookups if there is an expensive ON condition on the
inner table.
revno: 2876.47.174
revision-id: jorgen.loland@oracle.com-20110519120355-qn7eprkad9jqwu5j
parent: mayank.prasad@oracle.com-20110518143645-bdxv4udzrmqsjmhq
committer: Jorgen Loland <jorgen.loland@oracle.com>
branch nick: mysql-trunk-11765831
timestamp: Thu 2011-05-19 14:03:55 +0200
message:
BUG#11765831: 'RANGE ACCESS' MAY INCORRECTLY FILTER
AWAY QUALIFYING ROWS
The problem was that the ranges created when OR'ing two
conditions could be incorrect. Without the bugfix,
"I <> 6 OR (I <> 8 AND J = 5)" would create these ranges:
"NULL < I < 6",
"6 <= I <= 6 AND 5 <= J <= 5",
"6 < I < 8",
"8 <= I <= 8 AND 5 <= J <= 5",
"8 < I"
While the correct ranges is
"NULL < I < 6",
"6 <= I <= 6 AND 5 <= J <= 5",
"6 < I"
The problem occurs when key_or() ORs
(1) "NULL < I < 6, 6 <= I <= 6 AND 5 <= J <= 5, 6 < I" with
(2) "8 < I AND 5 <= J <= 5"
The reason for the bug is that in key_or(), SEL_ARG *tmp is
used to point to the range in (1) above that is merged with
(2) while key1 points to the root of the red-black tree of
(1). When merging (1) and (2), tmp refers to the "6 < I"
part whereas the root is the "6 <= ... AND 5 <= J <= 5" part.
key_or() decides that the tmp range needs to be split into
"6 < I < 8, 8 <= I <= 8, 8 < I", in which next_key_part of the
second range should be that of tmp. However, next_key_part is
set to key1->next_key_part ("5 <= J <= 5") instead of
tmp->next_key_part (empty). Fixing this gives the correct but
not optimal ranges:
"NULL < I < 6",
"6 <= I <= 6 AND 5 <= J <= 5",
"6 < I < 8",
"8 <= I <= 8",
"8 < I"
A second problem can be seen above: key_or() may create
adjacent ranges that could be replaced with a single range.
Fixes for this is also included in the patch so that the range
above becomes correct AND optimal:
"NULL < I < 6",
"6 <= I <= 6 AND 5 <= J <= 5",
"6 < I"
Merging adjacent ranges like this gives a slightly lower cost
estimate for the range access.
There is an optimization of DISTINCT in JOIN::optimize()
which depends on THD::used_tables value. Each SELECT statement
inside SP resets used_tables value(see mysql_select()) and it
leads to wrong result. The fix is to replace THD::used_tables
with LEX::used_tables.
mysql-test/r/sp.result:
test case
mysql-test/t/sp.test:
test case
sql/sql_base.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_class.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_class.h:
THD::used_tables is replaced with LEX::used_tables
sql/sql_insert.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_lex.h:
THD::used_tables is replaced with LEX::used_tables
sql/sql_prepare.cc:
THD::used_tables is replaced with LEX::used_tables
sql/sql_select.cc:
THD::used_tables is replaced with LEX::used_tables
This problem could be observed for queries with nested outer joins
for which the not_exist optimization were applicable.
The problem was caused by the code of the patch for bug #49322
that erroneously forced the return to the previous nested loop
level when the join algorithm successfully builds a partial record
for an embedded outer to which the not_exist optimization could be
applied.
Actually the immediate return to the previous nested loops level
is correct only if this partial record is rejected by a predicate
pushed down to one of the inner tables of this outer join. Otherwise
attempts to find extensions of this record must be made.
The problem is that TIME_FUZZY_DATE is explicitly used for get_arg0_date()
function in Item_date_typecast::get_date method. The fix is to use real
fuzzy_date value.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item_timefunc.cc:
use real fuzzy_date value
In case of two views with subqueries it is dificult to decide about order of injected ORDER BY clauses.
A simple solution is just prohibit ORDER BY injection if there is other order by.
mysql-test/r/view.result:
New test added, old test changed.
mysql-test/t/view.test:
New test aded.
sql/share/errmsg.txt:
new warning added.
sql/sql_view.cc:
Inject ORDER BY only if there is no other one.
Warning about ignoring ORDER BY in this case for EXPLAIN EXTENDED.
There are 2 volatile condition constructions AND/OR constructions and fields(references) when first
good supported to be top elements of conditions because it is normal practice
(see copy_andor_structure for example) fields without any expression in the condition is really rare
and mostly useless case however it could lead to problems when optimiser changes/moves them unaware
of other variables referring to them. An easy solution of this problem is just to replace single field
in a condition with equivalent expression well supported by the server (<field> -> <field> != 0).
mysql-test/r/view.result:
New test added.
mysql-test/t/view.test:
New test added.
sql/sql_parse.cc:
<field> -> <field> != 0
sql/sql_yacc.yy:
<field> -> <field> != 0
An aggregating query over an empty set of a join of two tables
with a rejecting HAVING clause erroneously could return a row.
It could happen in the cases when the optimizer made a conclusion
that the aggregating set was empty.
Wrong results were produced because the server missed initial
setting for aggregation functions in the mentioned cases.
The function matching_cond should take into account that
there may be always false constant conjunctive conditions
that has not been evaluated yet,for example, conjunctive
conditions with non-correlated subqueries.
ALL subquery should return TRUE if subquery rowa set is empty independently
of left part. The problem was that Item_func_(eq,ne,gt,ge,lt,le) do not
call execution of second argument if first is NULL no in this case subquery
will not be executed and when Item_func_not_all calls any_value() of the
subquery or aggregation function which report that there was rows. So for
NULL < ALL (SELECT...) result was FALSE instead of TRUE.
Fix is just swapping of arguments of Item_func_(eq,ne,gt,ge,lt,le) (with
changing the operation if it is needed) so that result will be the same
(for examole a < b is equal to b > a). This fix exploit the fact that
first argument will be executed in any case.
mysql-test/r/subselect.result:
The test suite added.
mysql-test/r/subselect_no_mat.result:
The test suite added.
mysql-test/r/subselect_no_opts.result:
The test suite added.
mysql-test/r/subselect_no_semijoin.result:
The test suite added.
mysql-test/r/subselect_scache.result:
The test suite added.
mysql-test/t/subselect.test:
The test suite added.
sql/item_cmpfunc.cc:
Swap arguments creation methods added.
sql/item_cmpfunc.h:
Swap arguments creation methods added.
sql/item_subselect.cc:
Swap arguments of the comparison.
reset_nj_counters() used to rely on the fact that join nests have
table->table==NULL. This ceased to be true wit new derived table
optimizations. Use test for table->nested_join!=NULL instead.
The problem was that optimizer removes some outer references (it they are
constant for example) and the list of outer items built during prepare phase is
not actual during execution phase when we need it as the cache parameters.
First solution was use pointer on pointer on outer reference Item and
initialize temporary table on demand. This solved most problem except case
when optimiser also reduce Item which contains outer references ('OR' in
this bug test suite).
The solution is to build the list of outer reference items on execution
phase (after optimization) on demand (just before temporary table creation)
by walking Item tree and finding outer references among Item_ident
(Item_field/Item_ref) and Item_sum items.
Removed depends_on list (because it is not neede any mnore for the cache, in the place where it was used it replaced with upper_refs).
Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references (or other expression parameters in future).
mysql-test/r/subselect_cache.result:
A new test added.
mysql-test/r/subselect_scache.result:
Changes in creating the cache and its paremeters order or adding arguments of aggregate function (which is a parameter also, but this has no influence on the result).
mysql-test/t/subselect_cache.test:
Added a new test.
sql/item.cc:
depends_on removed.
Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
Item_cache_wrapper collect parameters befor initialization of its cache.
sql/item.h:
depends_on removed.
Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
sql/item_cmpfunc.cc:
depends_on removed.
Added processor (collect_outer_ref_processor) to collect outer references.
sql/item_cmpfunc.h:
Added processor (collect_outer_ref_processor) to collect outer references.
sql/item_subselect.cc:
depends_on removed.
Added processor get_cache_parameters() method to collect outer references.
sql/item_subselect.h:
depends_on removed.
Added processor get_cache_parameters() method to collect outer references.
sql/item_sum.cc:
Added processor (collect_outer_ref_processor) method to collect outer references.
sql/item_sum.h:
Added processor (collect_outer_ref_processor) and get_cache_parameters() methods to collect outer references.
sql/opt_range.cc:
depends_on removed.
sql/sql_base.cc:
depends_on removed.
sql/sql_class.h:
New iterator added.
sql/sql_expression_cache.cc:
Build of list of items resolved in outer query done just before creating expression cache on the first execution of the subquery which removes influence of optimizer removing items (all optimization already done).
sql/sql_expression_cache.h:
Build of list of items resolved in outer query done just before creating expression cache on the first execution of the subquery which removes influence of optimizer removing items (all optimization already done).
sql/sql_lex.cc:
depends_on removed.
sql/sql_lex.h:
depends_on removed.
sql/sql_list.h:
Added add_unique method to add only unique elements to the list.
sql/sql_select.cc:
Support of new Item list added.
sql/sql_select.h:
Support of new Item list added.
Analysis:
Both the wrong result and the valgrind warning were a result
of incomplete cleanup of the MIN/MAX subquery rewrite. At the
first execution of the query, the non-aggregate subquery is
transformed into an aggregate MIN/MAX subquery. During the
fix_fields phase of the MIN/MAX function, it sets the property
st_select_lex::with_sum_func to true.
The second execution of the query finds this flag to be ON.
When optimization reaches the same MIN/MAX subquery
transformation, it tests if the subquery is an aggregate or not.
Since select_lex->with_sum_func == true from the previous
execution, the transformation executes the second branch that
handles aggregate subqueries. This substitutes the subquery
Item into a Item_maxmin_subselect. At the same time elsewhere
it is assumed that the subquery Item is of type
Item_allany_subselect. Ultimately this results in casting the
actual object to the wrong class, and calling the wrong
any_value() method from empty_underlying_subquery().
Solution:
Cleanup the st_select_lex::with_sum_func property in the case
when the MIN/MAX transformation was performed for a non-aggregate
subquery, so that the transformation can be repeated.
This bug could lead to wrong result sets for a query over a
materialized derived table or view accessed by a multi-component
key.
It happened because the function get_next_field_for_derived_key
was supposed to update its argument, and it did not do it.
Also:
1. simplified the code of the function mysql_derived_merge_for_insert.
2. moved merge of views/dt for multi-update/delete to the prepare stage.
3. the list of the references to the candidates for semi-join now is
allocated in the statement memory.
The buffer was simply too small.
In 5.5 and trunk, the size is 311 + 31,
in 5.1 and below, the size is 331
client/sql_string.cc:
Increase buffer size in String::set(double, ...)
include/m_string.h:
Increase FLOATING_POINT_BUFFER
mysql-test/r/type_float.result:
New test cases.
mysql-test/t/type_float.test:
New test cases.
sql/sql_string.cc:
Increase buffer size in String::set(double, ...)
sql/unireg.h:
Move definition of FLOATING_POINT_BUFFER
(This is not a real fix for this bug, even though it makes it to no longer repeat)
- Semi-join subquery predicates, i.e. ... WHERE outer_expr IN (SELECT ...) may have null-rejecting properties,
may allow to convert outer joins into inner.
- When convert_subq_to_sj() injected IN-equality into parent's WHERE/ON clause, it didn't call
$new_cond->top_level_item(), which would cause null-rejecting properties to be lost.
- Fixed, now the mentioned outer-to-inner conversion will really take place.
- Added an initial set of feature-specific test cases
- Handled the special case where the materialized subquery of an
IN predicates consists of only NULL values.
- Fixed a bug where making Item_in_subselect a constant,
didn't respect its null_value value.
Analysis:
For some of the re-executions of the correlated subquery the
where clause is false. In these cases the execution of the
subquery detects that it must generate a NULL row because of
implicit grouping. In this case the subquery execution reaches
the following code in do_select():
while ((table= li++))
mark_as_null_row(table->table);
This code marks all rows in the table as complete NULL rows.
In the example, when evaluating the field t2.f10 for the second
row, all bits of Field::null_ptr[0] are set by the previous call
to mark_as_null_row(). Then the call to Field::is_null()
returns true, resulting in a NULL for the MAX function.
Thus the lines above are not suitable for subquery re-execution
because mark_as_null_row() changes the NULL bits of each table
field, and there is no logic to restore these fields.
Solution:
The call to mark_as_null_row() was added by the fix for bug
lp:613029. Therefore removing the fix for lp:613029 corrects
this wrong result. At the same time the test for lp:613029
behaves correctly because the changes of MWL#89 result in a
different execution path where:
- the constant subquery is evaluated via JOIN::exec_const_cond
- detecting that it has an empty result triggers the branch
if (zero_result_cause)
return_zero_rows()
- return_zero_rows() calls mark_as_null_row().
The attribute not_null_tables could be calculated incorrectly in the
function SELECT_LEX::update_used_tables for queries over views
with row items in the WHERE clause. It happened because no
implementation of the virtual callback function eval_not_null_tables
was provided for the class Item_row.
Also slightly optimized the code calculating the value of the maybe_null
flag for tables in the function SELECT_LEX::update_used_tables.
Analysis:
This is a bug in MWL#68, where it was incorrectly assumed
that if there is a match in the only non-null key, then
if there is a covering NULL row on all remaining NULL-able
columns there is a partial match. However, this is not the case,
because even if there is such a null-only sub-row, it is not
guaranteed to be part of the matched sub-row. The matched sub-row
and the NULL-only sub-row may be parts of different rows.
In fact there are two cases:
- there is a complete row with only NULL values, and
- all nullable columns contain only NULL values.
These two cases were incorrectly mixed up in the class member
subselect_partial_match_engine::covering_null_row_width.
Solution:
The solution is to:
- split covering_null_row_width into two members:
has_covering_null_row, and has_covering_null_columns, and
- take into account each state during initialization and
execution.
In addition to the bug fix explained below, the patch performs
few renames, and adds some comments to avoid similar problems.
Analysis:
The failed assert was due to a bug in MWL#68, where it was
incorrectly assumed that the size of the bitmap
subselect_rowid_merge_engine::null_only_columns should be
the same as the size of the array of Ordered_keys.
The bitmap null_only_columns contains bits to mark columns
that contain only NULLs. Therefore the indexes of the bits
to be set in null_only_columns are different from the indexes
of the Ordered_keys. If there is a NULL-only column that appears
in a table after the last partial match column with Ordered_key,
this NULL-only column would require setting a bit with index
bigger than the size of the bitmap null_only_columns.
Accessing such a bit caused the failed assert.
Solution:
Upon analysis, it turns out that null_only_columns is not needed
at all, because we are looking for partial matches, and having
such columns guarantees that there is a partial match for any
corresponding outer value.
Therefore the patch removes
subselect_rowid_merge_engine::null_only_columns.
Second smaller hole in the polygon got link to the bigger one as it's the
outer ring. Fixed by specifying the outer ring explicitly.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #804266 Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #804266 Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.
test case added.
sql/gcalc_tools.cc
Fix for bug #804266 Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.
specify the outer ring explicitly in the get_polygon_result parameter.
sql/gcalc_tools.h
Fix for bug #804266 Memory corruption/valgrind warning/crash in move_hole() with ST_UNION.
add the outer ring as a parameter to the get_polygon_result.
The bitmap of used tables must be evaluated for the select list of every
materialized derived table / view and saved in a dedicated field.
This is also applied to materialized subqueries.
We cannot cut a line from a polygon. So if the polygon fits the condition, and
the intersection of a line and the polygon doesn't, we just skip the line.
That rule wasn't applied if the line start was inside the polygon, which leaded
to the assertion.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #801217 Assertion `t1->result_range' in Gcalc_operation_reducer::end_couple.
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #801217 Assertion `t1->result_range' in Gcalc_operation_reducer::end_couple.
test case added.
sql/gcalc_tools.cc
Fix for bug #801217 Assertion `t1->result_range' in Gcalc_operation_reducer::end_couple.
Don't mark the line as a border if it's inside a polygon that fits the result condition.
When CREATE TABLE wasn't given ENGINE=... it would determine
the default ENGINE at parse-time rather than at execution
time, leading to incorrect behaviour (namely, later changes
to the default engine being ignore) when calling CREATE TABLE
from a stored procedure.
We now defer working out the default engine till execution of
CREATE TABLE.
mysql-test/r/sp_trans.result:
results!
mysql-test/t/sp_trans.test:
Show that CREATE TABLE (called from store routine) heeds
any changes after CREATE SP / parse-time. Show that explicitly
requesting an ENGINE still works.
sql/sql_parse.cc:
If no ENGINE=... was given at parse-time, determine default
engine at execution time of CREATE TABLE.
sql/sql_yacc.yy:
If CREATE TABLE is not given ENGINE=..., don't bother
figuring out the default engine during parsing; we'll
do it at execution time instead to be aware of the
latest updates.
Bug#11766642: crash in Item_field::register_field_in_read_map
with view
(Former 59793)
Prior to the refactoring in this patch, Item_cond_xor behaved
partially as an Item_cond and partially as an Item_func. The
reasoning behind this was that XOR is currently not optimized
(thus should be Item_func instead of Item_cond), but it was
planned optimize it in the future (thus, made Item_cond anyway
to ease optimization later).
Even though Item_cond inherits from Item_func, there are
differences between these two. One difference is that the
arguments are stored differently. Item_cond stores them in a
list while Item_func store them in an args[].
BUG no 45221 was caused by Item_cond_xor storing arguments in
the list while users of the objects would look for them in
args[]. The fix back then was to store the arguments in both
locations.
In this bug, Item_cond_xor initially gets two Item_field
arguments. These are stored in the list inherited from
Item_cond and in args[] inherited from Item_func. During
resolution, find_field_in_view() replaces the Item_fields
stored in the list with Item_direct_view_refs, but args[]
still points to the unresolved Item_fields. This shows that
the fix for 45221 was incorrect.
The refactoring performed in this patch removes the confusion
by making the XOR item an Item_func period. A neg_transformer()
is also implemented for Item_func_xor to improve performance
when negating XOR expressions. An XOR is negated by negating
one of the operands.
We must allocate a larger ref_pointer_array. We failed to account for extra
items allocated here:
#0 find_order_in_list
uint el= all_fields.elements;
all_fields.push_front(order_item); /* Add new field to field list. */
ref_pointer_array[el]= order_item;
order->item= ref_pointer_array + el;
#1 setup_order
#2 setup_without_group
#3 JOIN::prepare
mysql-test/r/order_by.result:
New test case.
mysql-test/r/union.result:
New test case.
mysql-test/t/order_by.test:
New test case.
mysql-test/t/union.test:
New test case.
sql/sql_lex.cc:
find_order_in_list() may need some extra space, so multiply og_num by two.
sql/sql_union.cc:
For UNION, the 'n_sum_items' are accumulated in the "global_parameters" select_lex.
This number must be propagated to setup_ref_array()
When preparing a 'fake_select_lex' we need to use global_parameters->order_list
rather than fake_select_lex->order_list (see comments inside st_select_lex_unit::cleanup)
Missing initialization of the bitmap not_null_tables_cache to 0
in the function Item_func::eval_not_null_tables caused this bug.
This function is called indirectly from the function
SELECT_LEX::update_used_tables after merging mergeable views and
derived tables into the main query. The leaf tables of resulting
query may change their bitmap numbers after this merge. That's why
the not_null_tables_cache bitmaps must be updated. Due to the bug
mentioned above the result of the re-evaluation of the
not_null_tables_cache turned out to be incorrect in some cases.
This could trigger an invalid conversion of outer joins into
inner joins leading to invalid query result sets.
Also removed an implicit conversion from int to bool in the function
SELECT_LEX::update_used_tables.
The value of THD::used tables should be re-evaluated after merges
of views and derived tables into the main query.
Now it's done in the function SELECT_LEX::update_used_tables.
The re-evaluation of the 'used_table' bitmaps for the items
in HAVING, GROUP BY and ORDER BY clauses has been added as well.
The bug was caused by an incorrect code of the function
Item_direct_view_ref::replace_equal_field introduced in the
patch for bugs 717577, 724942. The function erroneously
returned the wrapped field instead of the Item_direct_view_ref
object itself in the cases when no replacement happened.
The bug masked two other minor bugs that could result in not
quite correct output of the EXPLAIN command for some queries.
They were fixed in the patch as well.
- Set the default
- Adjust the testcases so that 'new' tests are run with optimizations turned on.
- Pull out relevant tests from "irrelevant" tests and run them with optimizations on.
- Run range.test and innodb.test with both mrr=on and mrr=off
A polygon has no right to have holes that are actually points.
So just skip them when we collect the result of an operation.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #804259 Second assertion in Gis_geometry_collection::init_from_opresult.
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #804259 Second assertion in Gis_geometry_collection::init_from_opresult.
test case added.
sql/gcalc_tools.cc
Fix for bug #804259 Second assertion in Gis_geometry_collection::init_from_opresult.
Skip the point in the result if it's the hole inside a polygon.
The offending query returns a wrong result set because the optimizer
erroneously eliminated the where condition evaluated it to TRUE.
The cause of this wrong transformation was that the flag maybe_null
for an inner table of the outer join was not set to TRUE after the
table had replaced the wrapping view.
Now the function SELECT_LEX::update_used_tables resets the value
of the maybe_null flag for each leaf table of the query after all
merges of views have been done.
Just typo-style mistake. Should be '||' instead of '&&'.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #805860 Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #805860 Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.
test case added.
sql/item_geofunc.cc
Fix for bug #805860 Second assertion Assertion `n > 0 && n < SINUSES_CALCULATED*2+1' in get_n_sincos.
condition fixed.
Analysis:
This bug is yet another incarnation of the generic problem
where optimization of the outer query triggers evaluation
of a subquery, and this evaluation performs a destructive
change to the subquery plan. Specifically a temp table is
created for the DISTINCT operation that replaces the
original subquery table. Later, select_describe() attempts
to print the table name, however, there is no corresponding
TABLE_LIST object to the internal temp table, so we get a
crash. Execution works fine because it is not interested in
the corresponding TABLE_LIST object (or its name).
Solution:
Similar to other such bugs, block the evaluation of expensive
Items in convert_const_to_int().
There were actually two bugs. One was when the line that intersects itself
the intersection point treated as it doesn't belong to the line.
Second when edges partly coincide, wrong result produced when we try to find their
intersection.
per-file comments:
mysql-test/r/gis-precise.result
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
test result updated.
mysql-test/t/gis-precise.test
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
test case added.
sql/gcalc_slicescan.cc
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
skip the intersection if it just line that intersects itself.
sql/gcalc_tools.cc
Fix for bug #804324 Assertion 0 in Gcalc_scan_iterator::pop_suitable_intersection
if edges coincide, just pick the first coinciding poing as an intersection.
The function generate_derived_keys_for_table incorrectly handled
the cases when a materialized view or derived table could be accessed
by different keys on the same fields if these keys depended on the
same tables.
That crash happened with the complicated topology of the result.
If we found a hole in a polygon whose outside border was already
found, we need to paste the hole right after it and respectively
shift polygons after it. Also we need to update poly_position fields
in these polygons. That last thing wasn't properly done that led to the
crash.
To fix that we keep the list of the found polygons and update the
poly_positions that are bigger or equal to where we placed the next hole.
per-file comments:
mysql-test/r/gis-precise.result
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
test result updated.
mysql-test/t/gis-precise.test
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
test result added.
sql/gcalc_tools.cc
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
keep the list of the found polygons and update their poly_position fields respectively.
sql/gcalc_tools.h
bug #804305 Crash in wkb_get_double with ST_INTERSECTION.
Gcalc_result_receiver::move_hole interface changed.
The bug lp:798213 exposes a design flaw in --innodb-release-locks-early.
It does not work with InnoDB crash recovery, so it breaks transactional
integrety. So remove the feature.
semijoin=on,firstmatch=on,loosescan=on
to
semijoin=off,firstmatch=off,loosescan=off
Adjust the testcases:
- Modify subselect*.test and join_cache.test so that all tests
use the same execution paths as before (i.e. optimizations that
are being tested are enabled)
- Let all other test files run with the new default settings (i.e.
with new optimizations disabled)
- Copy subquery testcases from these files into t/subselect_extra.test
which will run them with new optimizations enabled.
Analysis:
This bug consists of two related problems that are
result of too early evaluation of single-row subqueries
during the optimization phase of the outer query.
Several optimizer code paths try to evaluate single-row
subqueries in order to produce a constant and use that
constant for further optimzation.
When the execution of the subquery peforms destructive
changes to the representation of the subquery, and these
changes are not anticipated by the subsequent optimization
phases of the outer query, we tipically get a crash or
failed assert.
Specifically, in this bug the inner-most suqbuery with
DISTINCT triggers a substitution of the original JOIN
object by a single-table JOIN object with a temp table
needed to perform the DISTINCT operation (created by
JOIN::make_simple_join).
This substitution breaks EXPLAIN because:
a) in the first example JOIN::cleanup no longer can
reach the original table of the innermost subquery, and
close all indexes, and
b) in this second test query, EXPLAIN attempts to print
the name of the internal temp table, and crashes because
the temp table has no name (NULL pointer instead).
Solution:
a) fully disable subquery evaluation during optimization
in all cases - both for constant propagation and range
optimization, and
b) change JOIN::join_free() to perform cleanup irrespective
of EXPLAIN or not.
The ::val_str() method has to return NULL if it calculated
the null_value, not just set the related flag.
per-file comments:
mysql-test/r/gis-precise.result
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
test result updated.
mysql-test/t/gis-precise.test
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
test case added.
sql/item_geofunc.cc
fix for bug #801212 Assertion with ST_INTERSECTION on NULL values
return NULL from the val_str if we get the null_value.
Collections were treated mistakenly, so the counter for the final UNION operation
received the wrong value.
As a fix we implement Item_func_buffer::Transporter::start_collection() method,
where we set the proper operation and the operand counter.
start_poly() and start_line() were also modified to function correctly for the
polygon as a part of a collection.
per-file comments:
mysql-test/r/gis-precise.result
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
test result updated.
mysql-test/t/gis-precise.test
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
test case added.
sql/item_geofunc.cc
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
start_collection() implemented.
sql/item_geofunc.h
bug #801199 Infinite recursion in Gcalc_function::count_internal with ST_BUFFER over MULTIPOINT
Item_func_buffer::Transporter::start_collection() defined.
The assert conditions in the functions Item_direct_ref_to_ident::transform
and Item_direct_ref_to_ident::compile could be not valid after constant
propagation when fields and field references may be substituted for constants.
Not only these invalid asserts have been removed, but the functions containing
them have been removed as well because now Item_ref::transform and
Item_ref::compile can be used instead of them.
- The client gets a progress report message that triggers a callback function if requested with mysql_options(MYSQL_PROGRESS_CALLBACK, function)
- Added Progress field last to 'show processlist'
- Stage, Max_stage and Progress field added to information_schema.progresslist
- The 'mysql' client by defaults enables progress reports when the output is a tty.
- Added progress_report_time time variable to configure how often progress reports is sent to client
Added read only system variable 'in_transaction' which is 1 if we have executed a BEGIN statement.
client/client_priv.h:
Added OPT_REPORT_PROGRESS
client/mysql.cc:
Added option --progress-reports (on by default if not batch mode)
Progress reports is written to stdout for long running commands
include/Makefile.am:
Added mysql/service_progress_report.h
include/myisamchk.h:
Added variables to be able to do progress reporting in Aria and later in MyISAM
include/mysql.h:
Added new mysql_options() parameter: MYSQL_PROGRESS_CALLBACK
include/mysql.h.pp:
Added new mysql_options() parameter: MYSQL_PROGRESS_CALLBACK
include/mysql/plugin.h:
Added functions for reporting progress.
include/mysql/plugin_auth.h.pp:
Added functions for reporting progress.
include/mysql_com.h:
Added CLIENT_PROGRESS mysql_real_connect() flag.
include/sql_common.h:
Added callback function for reporting progress
mysql-test/r/old-mode.result:
Ensure that SHOW PROGRESSLIST doesn't have the Progress column in old mode.
mysql-test/suite/funcs_1/datadict/datadict_priv.inc:
Added new column
mysql-test/suite/funcs_1/datadict/processlist_priv.inc:
Test all new PROCESSLIST columns
mysql-test/suite/funcs_1/r/is_columns_is.result:
Updated results
mysql-test/suite/funcs_1/r/is_columns_is_embedded.result:
Updated results
mysql-test/suite/funcs_1/r/is_columns_mysql_embedded.result:
Updated results
mysql-test/suite/funcs_1/r/is_tables_is_embedded.result:
Updated results
mysql-test/suite/funcs_1/r/processlist_priv_no_prot.result:
Updated results
mysql-test/suite/funcs_1/r/processlist_priv_ps.result:
Updated results
mysql-test/suite/funcs_1/r/processlist_val_no_prot.result:
Updated results
mysql-test/suite/funcs_1/r/processlist_val_ps.result:
Updated results
mysql-test/suite/pbxt/r/pbxt_locking.result:
Updated results
mysql-test/suite/pbxt/r/skip_name_resolve.result:
Updated results
mysql-test/t/old-mode.test:
Ensure that SHOW PROGRESSLIST doesn't have the Progress column in old mode.
plugin/handler_socket/handlersocket/Makefile.am:
Added -lmysqlservices
scripts/mytop.sh:
Made 'State' field width dynamic.
Added 'Progress' to process list display.
sql-common/client.c:
Added handling of progress messages.
Removed check_license() function.
sql/mysql_priv.h:
Added opt_progress_report_time
sql/mysqld.cc:
Added progress_report_time time variable to configure how often progress reports is sent to client
sql/protocol.cc:
Added net_send_progress_packet()
sql/protocol.h:
New prototypes
sql/set_var.cc:
Added variables progress_report_time and in_transaction
sql/sql_acl.cc:
Safety fix: Made client_capabilities ulonglong
sql/sql_class.cc:
Added interface functions for progress reporting
sql/sql_class.h:
Added varibles in THD for progress reporting.
Added CF_REPORT_PROGRESS
sql/sql_load.cc:
Added progress reporting for LOAD DATA INFILE
sql/sql_parse.cc:
Added CF_REPORT_PROGRESS for top level commands for which it's safe to send progress reports to client
sql/sql_show.cc:
Added Progress field last to 'show processlist'
Stage, Max_stage and Progress field added to information_schema.progresslist
sql/sql_table.cc:
Added progress reporting for ALTER TABLE
Added THD as argument to copy_data_between_tables()
storage/maria/ha_maria.cc:
Added progress reporting for check table, repair table, analyze table
Fixed a bug in start_bulk_insert() that caused alter table to always run with all keys enabled.
storage/maria/ma_check.c:
Added progress reporting
Remember old state before starting repair. This removes some warnings from optimize_table if create-with-sort fails.
storage/maria/ma_check_standalone.h:
Added dummy reporting function for standalone Aria programs.
storage/maria/ma_sort.c:
Added progress reporting
storage/maria/maria_chk.c:
Updated version
storage/maria/maria_def.h:
Added new prototypes
tests/mysql_client_test.c:
Added test case for progress reporting
