Create an Item_cache based on item's cmp_type, not result_type in
subselect_engine.
Use result_field in Item_cache_temporal::cache_value(),
just like all other Item_cache*::cache_value() do.
Points and lines should disappear if we got negative D.
To make it work properly inside the GEOMETRYCOLLECTION,
we add the empty operation there.
bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
The double->inernal coord conversion produced -0 (minus zero) on some data.
That minus-zero produces invalid comparison results when compared agains plus-zero.
So we fixed the gcalc_set_double() to avoid it.
per-file comments:
mysql-test/r/gis-precise.result
result updated.
mysql-test/t/gis-precise.test
tests for #977021 and #986977 added.
sql/gcalc_slicescan.cc
bug #986977. The gcalc_set_double fixed to not produce minus-zero.
sql/item_geofunc.cc
bug #977021. Add the NOOP for the disappearing features.
Analysis:
The reason for the wrong result is the interaction between constant
optimization (in this case 1-row table) and subquery optimization.
- First the outer query is optimized, and 'make_join_statistics' finds that
table t2 has one row, reads that row, and marks the whole table as constant.
This also means that all fields of t2 are constant.
- Next, we optimize the subquery in the end of the outer 'make_join_statistics'.
The field 'f2' is considered constant, with value '3'. The subquery predicate
is rewritten as the constant TRUE.
- The outer query execution detects early that the whole query result is empty
and calls 'return_zero_rows'. Since the query is with implicit grouping, we
have to produce one row with special values for the aggregates (depending on
each aggregate function), and NULL values for all non-aggregate fields. This
function calls 'no_rows_in_result' to set each aggregate function to the
default value when it aggregates over an empty result, and then calls
'send_data', which in turn evaluates each Item in the SELECT list.
- When evaluation reaches the subquery predicate, it executes the subquery
with field 'f2' having a constant value '3', and the subquery produces the
incorrect result '7'.
Solution:
Implement Item::no_rows_in_result for all subquery predicates. In order to
make this work, it is also needed to make all val_* methods of all subquery
predicates respect the Item_subselect::forced_const flag. Otherwise subqueries
are executed anyways, and override the default value set by no_rows_in_result
with whatever result is produced from the subquery evaluation.
As part of derived tables redesign, values for VIEW_ALGORITHM_MERGE and VIEW_ALGORITHM_TMPTABLE have changed from (former values 1 rsp 2 , new values 5 rsp 9).
This lead to the problem that views, created with version 5.2 or earlier would not work in all situations (e.g "SHOW CREATE VIEW"), or with mysqldump.
The fix is to restore backward compatibility for the from file, and convert algorithm={1,2} in the frm to {5,9} when reading .frm from disk, and store backward compatible values when writing from to disk.
Also allow processing correct processing for "invalid" .frms created with MariaDB 5.3/5.5 GA releases (where algorithm stored in memory matched the one stored in frm).
Points and lines should disappear if we got negative D.
To make it work properly inside the GEOMETRYCOLLECTION,
we add the empty operation there.
bug #986977 Assertion `!cur_p->event' failed in Gcalc_scan_iterator::arrange_event(int, int).
The double->inernal coord conversion produced -0 (minus zero) on some data.
That minus-zero produces invalid comparison results when compared agains plus-zero.
So we fixed the gcalc_set_double() to avoid it.
per-file comments:
mysql-test/r/gis-precise.result
result updated.
mysql-test/t/gis-precise.test
tests for #977021 and #986977 added.
sql/gcalc_slicescan.cc
bug #986977. The gcalc_set_double fixed to not produce minus-zero.
sql/item_geofunc.cc
bug #977021. Add the NOOP for the disappearing features.
Fixed incorrect type casting which made all fields (except very first) changes to materialized table incorrect.
Saved list of view/derived table used items after expanding '*'.
Part#1: make EXPLAIN's plan match the one by actual execution:
Item_subselect::used_tables() should return the same value irrespectively
of whether we're running an EXPLAIN or a SELECT.
Also, do not package aria log files in the zip package- not required for the database to function,
also will avoid trouble with recovery, if someone accidentially (or on purpose) upgrades by unpacking the zip in the existing install directory.
The class Copy_field contains a String tmp,
which may allocate memory on the heap.
That means that all instances of Copy_field
must be properly destroyed. Alas they are not.
Solution: don't use Copy_field::tmp for copying
from_field => tmp => to_field
in do_field_string()
sql/field.cc:
In Field_set::val_str
return empty string (of appropriate character set) for an empty set.
sql/field.h:
New private member in Field_enum: empty_set_string.
sql/field_conv.cc:
In do_field_string, use an auto variable for copying
from_field => tmp => to_field
rather than copy->tmp.
PROBLEM:
--------
When binary log statements are replayed on the slave, BEGIN is represented
in com_counters but COMMIT is not. Similarly in 'ROW' based replication
'INSERT','UPDATE',and 'DELETE' com_counters are not getting incremented
when the binary log statements are replayed at slave.
ANALYSIS:
---------
In 'ROW' based replication for COMMIT,INSERT,UPDATE and DELETE operations
following special events are invoked.
Xid_log_event,Write_rows_log_event,Update_rows_log_event,Update_rows_log_event.
The above mentioned events doesn't go through the parser where the
'COM_COUNTERS' are incremented.
FIX:
-----
Increment statements are added at appropriate events.
Respective functions are listed below.
'Xid_log_event::do_apply_event'
'Write_rows_log_event::do_before_row_operations'
'Update_rows_log_event::do_before_row_operations'
'Delete_rows_log_event::do_before_row_operations'
sql/log_event.cc:
Added code to increment counts for 'COM_INSERT','COM_UPDATE',
'COM_DELETE' and 'COM_COMMIT'during ROW based replicaiton
- Workaround linker bug that prevents linking aria test executables
using -fno-common on OSX
- Skip system readline detection (OSX readline is incompatible one)
- Make Xcode generator work
TABLES IN INCORRECT ENGINE
PROBLEM:
CREATE/ALTER TABLE currently can move system tables like
mysql.db, user, host etc, to engines other than MyISAM. This is not
completely supported as of now, by mysqld. When some of system tables
like plugin, servers, event, func, *_priv, time_zone* are moved
to innodb, mysqld restart crashes. Currently system tables
can be moved to BLACKHOLE also!!!.
ANALYSIS:
The problem is that there is no check before creating or moving
a system table to some particular engine.
System tables are suppose to be residing in MyISAM. We can think
of restricting system tables to exist only in MyISAM. But, there could
be future needs of these system tables to be part of other engines
by design. For eg, NDB cluster expects some tables to be on innodb
or ndb engine. This calls for a solution, by which system
tables can be supported by any desired engine, with minimal effort.
FIX:
The solution provides a handlerton interface using which,
mysqld server can query particular storage engine handlerton for
system tables that it supports. This way each storage engine
layer can define their own system database and system tables.
The check_engine() function uses the new handlerton function
ha_check_if_supported_system_table() to check if db.tablename
provided in the DDL is supported by the SE.
Note: This fix has modified a test in help.test, which was moving
mysql.help_* to innodb. The primary intention of the test was not
to move them between engines.
