Virtual columns of ENUM and SET data types were not supported properly
in the original patch that introduced virtual columns into MariaDB 5.2.
The problem was that for any virtual column the patch used the
interval_id field of the definition of the column in the frm file as
a reference to the virtual column expression.
The fix stores the optional interval_id of the virtual column in the
extended header of the virtual column expression.
Attempt to make it easier to upgrade mysql->mariadb on Ubuntu precise.
It looks like we were missing conflicts: and replaces: on packages
mysql-server-5.5 and mysql-client-5.5.
Problem: Some queries with subqueries and a HAVING clause that
consists only of a column not in the select or grouping lists causes
the server to crash.
During parsing, an Item_ref is constructed for the HAVING column. The
name of the column is resolved when JOIN::prepare calls fix_fields()
on its having clause. Since the column is not mentioned in the select
or grouping lists, a ref pointer is not found and a new Item_field is
created instead. The Item_ref is replaced by the Item_field in the
tree of HAVING clauses. Since the tree consists only of this item, the
pointer that is updated is JOIN::having. However,
st_select_lex::having still points to the Item_ref as the root of the
tree of HAVING clauses.
The bug is triggered when doing filesort for create_sort_index(). When
find_all_keys() calls select->cond->walk() it eventually reaches
Item_subselect::walk() where it continues to walk the having clauses
from lex->having. This means that it finds the Item_ref instead of the
new Item_field, and Item_ref::walk() tries to dereference the ref
pointer, which is still null.
The crash is reproducible only in 5.5, but the problem lies latent in
5.1 and trunk as well.
Fix: After calling fix_fields on the having clause in JOIN::prepare(),
set select_lex::having to point to the same item as JOIN::having.
This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
query is executed as a prepared statement. The Item_field is created
in the runtime arena when the query is prepared, and the pointer to
the item is saved by st_select_lex::fix_prepare_information() and
brought back as a dangling pointer when the query is executed, after
the runtime arena has been reclaimed.
Fix: Backport fix from trunk that switches to the permanent arena
before calling Item_ref::fix_fields() in JOIN::prepare().
sql/item.cc:
Set context when creating Item_field.
sql/sql_select.cc:
Switch to permanent arena and update select_lex->having.
- Changed output to be error "error-text" instead of error - error-text
extra/perror.c:
Move my_handler_errors.h into include
include/my_handler_errors.h:
Move my_handler_errors.h into include
mysql-test/r/errors.result:
Updated result
mysql-test/r/innodb_mysql_sync.result:
Updated result
mysql-test/r/myisam-system.result:
Updated result
mysql-test/r/myisampack.result:
Updated result
mysql-test/r/partition_innodb_plugin.result:
Updated result
mysql-test/r/ps_1general.result:
Updated result
mysql-test/r/trigger.result:
Updated result
mysql-test/r/type_bit.result:
Updated result
mysql-test/r/type_bit_innodb.result:
Updated result
mysql-test/r/type_blob.result:
Updated result
mysql-test/suite/archive/archive.result:
Updated result
mysql-test/suite/binlog/r/binlog_index.result:
Updated result
mysql-test/suite/binlog/r/binlog_ioerr.result:
Updated result
mysql-test/suite/csv/csv.result:
Updated result
mysql-test/suite/engines/iuds/r/type_bit_iuds.result:
Updated result
mysql-test/suite/federated/federated_bug_35333.result:
Updated result
mysql-test/suite/innodb/r/innodb-create-options.result:
Updated result
mysql-test/suite/innodb/r/innodb-index.result:
Updated result
mysql-test/suite/innodb/r/innodb-zip.result:
Updated result
mysql-test/suite/innodb/r/innodb.result:
Updated result
mysql-test/suite/innodb/r/innodb_bug13635833.result:
Updated result
mysql-test/suite/innodb/r/innodb_bug21704.result:
Updated result
mysql-test/suite/innodb/r/innodb_bug46000.result:
Updated result
mysql-test/suite/parts/r/partition_bit_innodb.result:
Updated result
mysql-test/suite/parts/r/partition_bit_myisam.result:
Updated result
mysql-test/suite/percona/percona_innodb_fake_changes.result:
Updated result
mysql-test/suite/perfschema/r/misc.result:
Updated result
mysql-test/suite/perfschema/r/privilege.result:
Updated result
mysql-test/suite/rpl/r/rpl_EE_err.result:
Updated result
mysql-test/suite/rpl/r/rpl_binlog_errors.result:
Updated result
mysql-test/suite/rpl/r/rpl_drop_db.result:
Updated result
sql/share/errmsg-utf8.txt:
Removed 'column' from error text that was used in different context
strings/my_vsnprintf.c:
Move my_handler_errors.h into include
Minor cleanups
Changed output of %M to be error "error-text" instead of error - error-text
unittest/mysys/my_vsnprintf-t.c:
Updated error text
make sure that find_date_time_item() is called before agg_arg_charsets_for_comparison().
optimize Item_func_conv_charset to avoid conversion if no string result is needed
On localized Windows versions, Windows uses localized time zone names and contain non-ASCII characters. non-ASCII characters appear broken when displayed by clients
The fix is to declare system_time_zone variable to have UTF8 encoding and to convert tzname to UTF8.
mysql-test/suite/sphinx/sphinx.result:
Removed sphinx_time, as it was depending on timing.
mysql-test/suite/sphinx/sphinx.test:
Removed sphinx_time, as it was depending on timing.
mysqldump with --include-master-host-port putting quotes around port number
Patch from Stewart Smith
client/mysqldump.c:
Remove quotes from MASTER_PORT
sql/sql_table.cc:
Added comment
storage/maria/ma_close.c:
Don't store history if it's visible to all.
This fixed the MDEV-306 bug
storage/maria/ma_delete_table.c:
Removed old comment
Delete history state for deleted tables
storage/maria/ma_info.c:
More DBUG_PRINT
storage/maria/ma_open.c:
More DBUG_PRINT
Analysis:
The fix for bug lp:985667 implements the method Item_subselect::no_rows_in_result()
for all main kinds of subqueries. The purpose of this method is to be called from
return_zero_rows() and set Items to some default value in the case when a query
returns no rows. Aggregates and subqueries require special treatment in this case.
Every implementation of Item_subselect::no_rows_in_result() called
Item_subselect::make_const() to set the subquery predicate to its default value
irrespective of where the predicate was located in the query. Once the predicate
was set to a constant it was never executed.
At the same time, the JOIN object of the fake select for UNIONs (the one used for
the final result of the UNION), was set after all subqueries in the union were
executed. Since we set the subquery as constant, it was never executed, and the
corresponding JOIN was never created.
In order to decide whether the result of NOT IN is NULL or FALSE, Item_in_optimizer
needs to check if the subquery result was empty or not. This is where we got the
crash, because subselect_union_engine::no_rows() checks for
unit->fake_select_lex->join->send_records, and the join object was NULL.
Solution:
If a subquery is in the HAVING clause it must be evaluated in order to know its
result, so that we can properly filter the result records. Once subqueries in the
HAVING clause are executed even in the case of no result rows, this specific
crash will be solved, because the UNION will be executed, and its JOIN will be
constructed. Therefore the fix for this crash is to narrow the fix for lp:985667,
and to apply Item_subselect::no_rows_in_result() only when the subquery predicate
is in the SELECT clause.
The class Item_func missed an implementation of the virtual
function update_null_value.
Back-ported the fix for bug 62125 from mysql 5.6 code line.
The test case was also back-ported.
Analysis:
Queries with implicit grouping (there is aggregate, but no group by)
follow some non-obvious semantics in the case of empty result set.
Aggregate functions produce some special "natural" value depending on
the function. For instance MIN/MAX return NULL, COUNT returns 0.
The complexity comes from non-aggregate expressions in the select list.
If the non-aggregate expression is a constant, it can be computed, so
we should return its value, however if the expression is non-constant,
and depends on columns from the empty result set, then the only meaningful
value is NULL.
The cause of the wrong result was that for subqueries the optimizer didn't
make a difference between constant and non-constant ones in the case of
empty result for implicit grouping.
Solution:
In all implementations of Item_subselect::no_rows_in_result() check if the
subquery predicate is constant. If it is constant, do not set it to the
default value for implicit grouping, instead let it be evaluated.
cmake/maintainer.cmake:
Add -DFORCE_INIT_OF_VARS to not get warnings generated by -Wall
configure.cmake:
Don't add -Wall if we already have it. This is to not enable options that are already turned off.
support-files/compiler_warnings.supp:
Removed suppression that is not needed anymore
INC_HOST_ERRORS() IS CALLED.
Issue : Sequence of calling inc_host_errors()
and reset_host_errors() required some
changes in order to maintain correct
connection error count.
Solution : Call to reset_host_errors() is shifted
to a location after which no calls to
inc_host_errors() are made.
client/mysqldump.c:
Added LINT_INIT
mysql-test/mysql-test-run.pl:
Disable warning if example engine is not found
mysql-test/suite/rpl/t/rpl_semi_sync.test:
Rpl_semi_sync_master_yes_tx may be different on Windows
sql/sql_plugin.cc:
More DBUG_PRINT
support-files/compiler_warnings.supp:
Disable some innobase warnings
unittest/mysys/my_vsnprintf-t.c:
Fixed test failure on Solaris (typo)
CRASHES INNODB | TRX_STATE_NOT_STARTED
The problem was that if DELETE with subselect caused a
deadlock inside InnoDB, this deadlock was not properly
handled by the SQL layer. This meant that the SQL layer
would try to unlock the row after InnoDB had rolled
back the transaction. This caused an assertion inside
InnoDB.
This patch fixes the problem by checking for errors
reported by SQL_SELECT::skip_record() and not calling
unlock_row() if any errors have been reported.
"INSTALL" was wrong, happens too late,
but "CONFIGURE_FILES(... COPYONLY)" should hopefully do it.
Traditional RPMs need to be checked, the above might fix their issues.
Problem
========
Replication breaks in the cases if the event length exceeds
the size of master Dump thread's max_allowed_packet.
The reason why this failure is occuring is because the event length is
more than the total size of the max_allowed_packet, on addition of the
max_event_header length exceeds the max_allowed_packet of the DUMP thread.
This causes the Dump thread to break replication and throw an error.
That can happen e.g with row-based replication in Update_rows event.
Fix
====
The problem is fixed in 2 steps:
1.) The Dump thread limit to read event is increased to the upper limit
i.e. Dump thread reads whatever gets logged in the binary log.
2.) On the slave side we increase the the max_allowed_packet for the
slave's threads (IO/SQL) by increasing it to 1GB.
This is done using the new server option (slave_max_allowed_packet)
included, is used to regulate the max_allowed_packet of the
slave thread (IO/SQL) by the DBA, and facilitates the sending of
large packets from the master to the slave.
This causes the large packets to be received by the slave and apply
it successfully.
sql/log_event.cc:
The max_allowed_packet is not evaluated to the new option
slave_max_allowed_packet after the fix.
sql/log_event.h:
Added the new option in the log_event.h file.
sql/mysqld.cc:
Added a new option to the server.
sql/slave.cc:
Increasing the session max_allowed_packet to a large value,
i.e. not taking global(max_allowed) into consideration, for the slave's threads.
sql/sql_repl.cc:
The dump thread's max_allowed_packet is set to the upper limit
which makes it independent and it now reads whatever gets
logged in the binary log.
One of the reported problems manifested itself in the scenario when one
thread tried to to get statistics on a key cache while the second thread
had not finished initialization of the key cache structure yet.
The problem was resolved by forcing serialization of such operations
on key caches.
To serialize function calls to perform certain operations over a key cache
a new mutex associated with the key cache now is used. It is stored in the
field op_lock of the KEY_CACHE structure. It is locked when the operation
is performed. Some of the serialized key cache operations utilize calls
for other key cache operations. To avoid recursive locking of op_lock
the new functions that perform the operations of key cache initialization,
destruction and re-partitioning with an additional parameter were introduced.
The parameter says whether the operation over op_lock are to be performed or
are to be omitted. The old functions for the operations of key cache
initialization, destruction,and re-partitioning now just call the
corresponding new functions with the additional parameter set to true
requesting to use op_lock while all other calls of these new function
have this parameter set to false.
Another problem reported in the bug entry concerned the operation of
assigning an index to a key cache. This operation can be called
while the key cache structures are not initialized yet. In this
case any call of flush_key_blocks() should return without any actions.
No test case is provided with this patch.
