The binlog_cache_use is incremented twice when changes to a transactional table
are committed, i.e. TC_LOG_BINLOG::log_xid calls is called. The problem happens
because log_xid calls both binlog_flush_stmt_cache and binlog_flush_trx_cache
without checking if such caches are empty thus unintentionally increasing the
binlog_cache_use value twice.
Although not explicitly mentioned in the bug, the binlog_cache_disk_use presents
the same problem.
The binlog_cache_use and binlog_cache_disk_use are status variables that are
incremented when transactional (i.e. trx-cache) or non-transactional (i.e.
stmt-cache) changes are committed. They are used to compute the ratio between
the use of disk and memory while gathering updates for a transaction.
The problem reported is fixed by avoiding incrementing the binlog_cache_use
and binlog_cache_disk_use if a cache is empty. We also have decided to increment
both variables when a cache is truncated as the cache is used although its
content is discarded and is not written to the binary log.
In this patch, we take the opportunity to re-organize the code around the
function binlog_flush_trx_cache and binlog_flush_stmt_cache.
It was possible to issue an ALTER TABLE ADD PRIMARY KEY on
an partitioned InnoDB table that failed and crashed the server.
The problem was that it succeeded to create the PK on at least
one partition, and then failed on a subsequent partition, due to
duplicate key violation. Since the partitions that already had added
the PK was not reverted all partitions was not consistent with the
table definition, which caused the crash.
The solution was to add a revert step to ha_partition::add_index()
that dropped the index for the already succeeded partitions, on failure.
Small fix for the test case. The column named "slow" was
used twice in the SELECTs. As a consequence, the column
named "ignore_server_ids" was not used.
To fix this we simply replace the second column selected
named "slow" with a column named "ignore_server_ids".
MySQL officially supports DATE values starting from 1000-01-01. This is
enforced for int values, but not for string values, thus one
could easily insert '0001-01-01' value. Int values are checked by
number_to_datetime function and Item_cache_datetime::val_str uses it
to fill MYSQL_TIME struct out of cached int value. This leads to the
scenario where Item_cache_datetime caches a non-null datetime value and when
it tries to convert it from int to string number_to_datetime function
treats the value as out-of-range and returns an error and
Item_cache_datetime::val_str returns NULL for a non-null value. Due to this
inconsistency server crashes.
Now number_to_datetime allows DATE values below 1000-01-01 if the
TIME_FUZZY_DATE flag is set. Better NULL handling for Item_cache_datetime.
Added the Item_cache_datetime::store function to reset str_value_cached flag
when an item is stored.
Assertion `fixed == 1' failed
Followup patch. Test case relied on system variable that is
only available if replication is compiled in. Replaced with
variable available in all builds.
If a relative path is supplied to option --defaults-file or
--defaults-extra-file, the server will crash when executing
an INSTALL PLUGIN command. The reason is that the defaults
file is initially read relative the current working directory
when the server is started, but when INSTALL PLUGIN is executed,
the server has changed working directory to the data directory.
Since there is no check that the call to my_load_defaults()
inside mysql_install_plugin(), the subsequence call to
free_defaults() will crash the server.
This patch fixes the problem by:
- Prepending the current working directory to the file name when
a relative path is given to the --defaults-file or --defaults-
extra-file option the first time my_load_defaults() is called,
which is just after the server has started in main().
- Adding a check of the return value of my_load_defaults() inside
mysql_install_plugin() and aborting command (with an error) if
an error is returned.
- It also adds a check of the return value for load_defaults in
lib_sql.cc for the embedded server since that was missing.
To test that the relative files for the options --defaults-file and
--defaults-extra-file is handled properly, mysql-test-run.pl is also
changed to not add a --defaults-file option if one is provided in the
tests *.opt file.
Assertion `fixed == 1' failed
(also fixes duplicate bug 57515)
agg_item_set_converter() (item.cc) handles conversion of
character sets by creating a new Item. fix_fields() is then
called on this newly created item. Prior to this patch, it was
not checked whether fix_fields() was successful or not. Thus,
agg_item_set_converter() would return success even when an
error occured. This patch makes it return error (TRUE) if
fix_fields() fails.
This crash could happen if SHOW CREATE VIEW indirectly failed to open a
view due to failures to open underlying tables (or functions). Several
such errors were hidden and converted to ER_VIEW_INVALID warnings to
prevent exposing details of underlying tables for which the user have
no privileges.
However, with the changes introduced by the patch for Bug#52044,
failing to open a view will cause opened tables, views and functions
to be closed. Since the errors causing these failures were converted
to warnings, SHOW CREATE VIEW would try to continue. This made it
possible to try to access memory that had been freed, causing a crash.
This patch fixes the problem by not closing opened tables, views and
functions in these cases. This allows SHOW CREATE VIEW to continue
and also prevents it from accessing freed memory.
Test case added to lock_sync.test.
Before this fix, the performance schema tables were defined in UPPERCASE.
This was incompatible with the lowercase_table_names option, and caused
issues with the install / upgrade process, when changing the lower case
table names setting *after* the install or upgrade.
With this fix, all performance schema tables are exposed with lowercase names.
As a result, the name of the performance schema table is always lowercase,
no matter how / if / when the lowercase_table_names setting if changed.
In MySQL 5.5 the new reserved words include:
SLOW as in FLUSH SLOW LOGS
GENERAL as in FLUSH GENERAL LOGS
IGNORE_SERVER_IDS as in CHANGE MASTER ... IGNORE_SERVER_IDS
MASTER_HEARTBEAT_PERIOD as in CHANGE MASTER ... MASTER_HEARTBEAT_PERIOD
These are not reserved words in standard SQL, or in Oracle 11g,
and as such, may affect existing applications.
We fix this by adding the new words to the list of
keywords that are allowed for labels in SPs.
removed and replaced by the comprehensive innodb-create-options.test.
It uses the rules listed in the comments at the top of that test.
This patch introduces these differences from previous behavior;
1) KEY_BLOCK_SIZE=0 is allowed by Innodb in both strict and non-strict mode
with no errors or warnings. It was previously used by the server to set
KEY_BLOCK_SIZE to undefined. (Bug#56628)
2) An explicit valid non-DEFAULT ROW_FORMAT always takes priority over a
valid KEY_BLOCK_SIZE. (bug#56632)
3) Automatic use of COMPRESSED row format is only done if the ROW_FORMAT
is DEFAULT or unspecified.
4) ROW_FORMAT=FIXED is prevented in strict mode.
This patch also includes various formatting changes for consistency with
InnoDB coding standards.
Related Bugs
Bug#54679: ALTER TABLE causes compressed row_format to revert to compact
Bug#56628: ALTER TABLE .. KEY_BLOCK_SIZE=0 produces untrue warning or unnecessary error
Bug#56632: ALTER TABLE implicitly changes ROW_FORMAT to COMPRESSED
removed and replaced by the comprehensive innodb-create-options.test.
It uses the rules listed in the comments at the top of that test.
This patch introduces these differences from previous behavior;
1) KEY_BLOCK_SIZE=0 is allowed by Innodb in both strict and non-strict mode
with no errors or warnings. It was previously used by the server to set
KEY_BLOCK_SIZE to undefined. (Bug#56628)
2) An explicit valid non-DEFAULT ROW_FORMAT always takes priority over a
valid KEY_BLOCK_SIZE. (bug#56632)
3) Automatic use of COMPRESSED row format is only done if the ROW_FORMAT
is DEFAULT or unspecified.
4) ROW_FORMAT=FIXED is prevented in strict mode.
This patch also includes various formatting changes for consistency with
InnoDB coding standards.
Related Bugs
Bug#54679: ALTER TABLE causes compressed row_format to revert to compact
Bug#56628: ALTER TABLE .. KEY_BLOCK_SIZE=0 produces untrue warning or unnecessary error
Bug#56632: ALTER TABLE implicitly changes ROW_FORMAT to COMPRESSED
Replace the array of mutexes that used to protect
dict_index_t::stat_n_diff_key_vals[] with an array of rw locks that protects
all the stats related members in dict_table_t and all of its indexes.
Approved by: Jimmy (rb://503)
1. Fixed the name of the table to proxies_priv
2. Fixed the column names to be of the form Capitalized_lowecarse instead of
Capitalized_Capitalized
3. Added Timestamp and Grantor columns
4. Added tests to plugin_auth to check the table structure
5. Updated the existing tests
by a function and column
The bugreport reveals two different bugs about grouping
on a function:
1) grouping by the TIME_TO_SEC function result caused
a server crash or wrong results and
2) grouping by the function returning a blob caused
an unexpected "Duplicate entry" error and wrong
result.
Details for the 1st bug:
TIME_TO_SEC() returns NULL if its argument is invalid (empty
string for example). Thus its nullability depends not only
on the nullability of its arguments but also on their values.
Fixed by (overoptimistically) setting TIME_TO_SEC() to be
nullable despite the nullability of its arguments.
Details for the 2nd bug:
The server is unable to create indices on blobs without
explicit blob key part length. However, this fact was
ignored for blob function result fields of GROUP BY
intermediate tables.
Fixed by disabling GROUP BY index creation for blob
function result fields like regular blob fields.
Adds deprecation warning for the mysqlbinlog options
--base64-output=always and --base64-output.
A warning is printed when the flags are used,
and also when running mysqlbinlog --help.
This crash could happen if TRUNCATE TABLE indirectly failed to open a
merge table due to failures to open underlying tables. Even if opening
failed, the TRUNCATE TABLE code would try to invalidate the table in
the query cache. Since this table had been closed and memory released,
this could lead to a crash.
This bug was introduced by a combination of the changes introduced by
the patch for Bug#52044, where failing to open a table will cause opened
tables to be closed. And the changes in patch for Bug#49938, where
TRUNCATE TABLE uses the standard open tables function.
This patch fixes the problem by setting the TABLE pointer to NULL before
invalidating the query cache.
Test case added to truncate_coverage.test.
Lines below which were added in the patch for Bug#56814 cause this crash:
+ if (table->table)
+ table->table->maybe_null= FALSE;
Consider following test case:
--
CREATE TABLE t1(f1 INT NOT NULL);
INSERT INTO t1 VALUES (16777214),(0);
SELECT COUNT(*) FROM t1 LEFT JOIN t1 t2
ON 1 WHERE t2.f1 > 1 GROUP BY t2.f1;
DROP TABLE t1;
--
We set TABLE::maybe_null to FALSE for t2 table
and in create_tmp_field() we create appropriate tmp table field
using create_tmp_field_from_item() function instead of
create_tmp_field_from_field. As a result we have
LONGLONG field. As we have GROUP BY clause we calculate
group buffer length, see calc_group_buffer().
Item from group list which is used for calculation
refer to the field from real tables and have LONG type.
So group buffer length become insufficient for storing of
LONGLONG value. It leads to overwriting of wrong memory
area in do_field_int() function which is called from
end_update().
After some investigation I found out that
create_tmp_field_from_item() is used only for OLAP
grouping and can not be used for common grouping
as it could be an incompatibility between tmp
table fields and group buffer length.
We can not remove create_tmp_field_from_item() call from
create_tmp_field as OLAP needs it and we can not use this
function for common grouping. So we should remove setting
TABLE::maybe_null to FALSE from simplify_joins().
In this case we'll get wrong behaviour of
list_contains_unique_index() back. To fix it we
could use Field::real_maybe_null() check instead of
Field::maybe_null() and add addition check of
TABLE_LIST::outer_join.
The problem is caused by bug49487 fix and became visible
after after bug56679 fix.
Items are cleaned up and set to unfixed state after filling derived table.
So we can not rely on item::fixed state in Item_func_group_concat::print
and we can not use 'args' array as items there may be cleaned up.
The fix is always to use orig_args array of items as it
always should contain the correct data.
The problem is dividing by const value when
the result is out of supported range.
The fix:
-return LONGLONG_MIN if the result is out of supported range for DIV operator.
-return 0 if divisor is -1 for MOD operator.
The problem was that the warnings risen by a trigger were not cleared upon
successful completion. The warnings should be cleared if the trigger completes
successfully.
The fix is to skip merging warnings into caller's Warning Info for triggers.
