In the string context the MIN() and MAX() functions don't take
into account the unsignedness of the UNSIGNED BIGINT argument
column.
I.e.:
CREATE TABLE t1 (a BIGINT UNSIGNED);
INSERT INTO t1 VALUES (18446668621106209655);
SELECT CONCAT(MAX(a)) FROM t1;
returns -75452603341961.
mysql-test/r/func_group.result:
Test case for bug #11766094.
mysql-test/t/func_group.test:
Test case for bug #11766094.
sql/item.cc:
Bug #11766094 - 59132: MIN() AND MAX() REMOVE UNSIGNEDNESS
The Item_cache_int::val_str() method has been modified to
take into account the unsigned_flag value when converting
data to string.
Valgrind warning happens due to missing NULL value check in
Item::get_date. The fix is to add this check.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item.cc:
added check for NULL value
Valgrind warning happens because null values check happens too late
in Item_func_month::val_str(after result string calculation).The fix
is to check null value before result string calculation.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item_timefunc.h:
check null value before result string calculation.
The LGPL license is used in some legacy code, and to
adhere to current licensing polity, we remove those
files that are no longer used, and reorganize the
remaining LGPL code so it will be GPL licensed from
now on.
Note: This patch only removed LGPL licensed files
in MySQL 5.5 and later, and is the third of a
set of patches to remove LGPL from all trees.
(See Bug# 11840513 for details)
ASSERTION TABLE->DB_STAT FAILED IN
SQL_BASE.CC::OPEN_TABLE() DURING I_S Q
This assert could be triggered if a statement requiring a name
lock on a table (e.g. DROP TRIGGER) executed concurrently
with an I_S query which also used the table.
One connection first started an I_S query that opened a given table.
Then another connection started a statement requiring a name lock
on the same table. This statement was blocked since the table was
in use by the I_S query. When the I_S query resumed and tried to
open the table again as part of get_all_tables(), it would encounter
a table instance with an old version number representing the pending
name lock. Since I_S queries ignore version checks and thus pending
name locks, it would try to continue. This caused it to encounter
the assert. The assert checked that the TABLE instance found with a
different version, was a real, open table. However, since this TABLE
instance instead represented a pending name lock, the check would
fail and trigger the assert.
This patch fixes the problem by removing the assert. It is ok for
TABLE::db_stat to be 0 in this case since the TABLE instance can
represent a pending name lock.
Test case added to lock_sync.test.
Valgrind warning happens due to missing NULL value check in
Item_func::val_decimal. The fix is to add this check.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item_func.cc:
added check for NULL value
Valgrind warning happens due to uninitialized cached_format_type field
which is used later in Item_func_str_to_date::val_str method.
The fix is to init cached_format_type field.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item_timefunc.cc:
init cached_format_type field
The LGPL license is used in some legacy code, and to
adhere to current licensing polity, we remove those
files that are no longer used, and reorganize the
remaining LGPL code so it will be GPL licensed from
now on.
Note: This patch only removed LGPL licensed files
in MySQL 5.1, and is the second of a set of
patches to remove LGPL from all trees.
(See Bug# 11840513 for details)
Assert fails due to overflow which happens in
Item_func_int_val::fix_num_length_and_dec() as
geometry functions have max_length value equal to
max_field_size(4294967295U). The fix is to skip
max_length calculation for some boundary cases.
mysql-test/r/func_math.result:
test case
mysql-test/t/func_math.test:
test case
sql/item_func.cc:
skip max_length calculation
if argument max_length is near max_field_size.
Assertion happens due to missing initialization of unsigned_flag
for Item_func_set_user_var object. It leads to incorrect
calculation of decimal field size.
The fix is to add initialization of unsigned_flag.
mysql-test/r/variables.result:
test case
mysql-test/t/variables.test:
test case
sql/item_func.cc:
add initialization of unsigned_flag.
Valgrind warining happens due to missing
'end of the string' check. The fix is to
check if we reached the end of the string.
mysql-test/r/func_time.result:
test case
mysql-test/t/func_time.test:
test case
sql/item_timefunc.cc:
check if we reached the end of
the string after leading spaces skipping.
ARE NOT BEING HONORED
max_allowed_packet works in conjunction with net_buffer_length.
max_allowed_packet is an upper bound of net_buffer_length.
So it doesn't make sense to set the upper limit lower than the value.
Added a warning (using ER_UNKNOWN_ERRROR and a specific message)
when this is done (in the log at startup and when setting either
max_allowed_packet or the net_buffer_length variables)
Added a test case.
Fixed several tests that broke the above rule.
(aka BUG#11766883)
- fix review comments
- Rewrite last usage of handler::get_tablespace_name to use
table->s->tablespace directly
- Remove(revert) the addition of default implementation for
handler::get_tablespace_name
- Add comments describing the new TABLE_SHARE members default_storage_media
and tablespace
- Fix usage of incorrect mask for column_format bits, i.e COLUMN_FORMAT_MASK
The slave was not able to find the correct row in the innodb
table, because the row fetched from the innodb table would not
match the before image. This happened because the (don't care)
bytes in the NULLed fields would change once the row was stored
in the storage engine (from zero to the default value). This
would make bulk memory comparison (using memcmp) to fail.
We fix this by taking a preventing measure and avoiding memcmp
for tables that contain nullable fields. Therefore, we protect
the slave search routine from engines that return arbitrary
values for don't care bytes (in the nulled fields). Instead, the
slave thread will only check null_bits and those fields that are
not set to NULL when comparing the before image against the
storage engine row.
mysql-test/extra/rpl_tests/rpl_record_compare.test:
Added test case to the include file so that this is tested
with more than one engine.
mysql-test/suite/rpl/r/rpl_row_rec_comp_innodb.result:
Result update.
mysql-test/suite/rpl/r/rpl_row_rec_comp_myisam.result:
Result update.
mysql-test/suite/rpl/t/rpl_row_rec_comp_myisam.test:
Moved the include file last, so that the result from
BUG#11766865 is not intermixed with the result for
BUG#11760454.
sql/log_event.cc:
Skips memory comparison if the table has nullable
columns and compares only non-nulled fields in the
field comparison loop.
prepared statements with cursor protocol).
The problem was a bug in Materialized-cursor implementation.
Materialized_cursor::open() called send_result_metadata()
with items pointing to already closed table.
The fix is to send metadata when the table is still open.
NOTE: this is a "partial" fix: metadata are different with
and without --cursor-protocol, but that's a different large
problem, one indication of which is reported as Bug 24176.
Issue:
------
Due to prefix match, database like 'k' was matching with 'ka' and events of 'ka' we getting displayed for 'show event' of 'k'.
Resolution:
-----------
Scan for listing of events in a schema is made to be done on exact match of database (schema) name instead of just prefix.
mysql-test/r/events_bugs.result:
modified expected file with the expected results.
mysql-test/t/events_bugs.test:
added a test case to reproduce the scenario.
sql/event_db_repository.cc:
Scan for schema name is made to be done on exact db name match.
configuration wizard to fail
Made the fields mysql.user.plugin and mysql.user.authentication_string
nullable to conform with some older clients doing inserts instead of
using the commands.
Regression from bug#11766232.
m_last_part could be set beyond the last partition.
Fixed by only setting it if within the limit.
Also added check in print_error.
Currently, rpl_semi_sync is failing in PB due to the warning message:
"Slave SQL: slave SQL thread is being stopped in the middle of "
"applying of a group having updated a non-transaction table; "
"waiting for the group completion ..."
The problem started happening after the fix for BUG#11762407 what was
automatically suppressing some warning messages.
To fix the current issue, we suppress the aforementioned warning message
and exploit the opportunity to make the sentence clearer.
of service in prepared statements).
sql/sql_prepare.cc:
At mysql_stmt_get_longdata(): instead of pushing an internal
error handler (as done in 5.1-tree) we save, set and restore
the statement's diagnostics area and warning info.
The problem was that server didn't check resulting size of prepared
statement argument which was set using mysql_send_long_data() API.
By calling mysql_send_long_data() several times it was possible
to create overly big string and thus force server to allocate
memory for it. There was no way to limit this allocation.
The solution is to add check for size of result string against
value of max_long_data_size start-up parameter. When intermediate
string exceeds max_long_data_size value an appropriate error message
is emitted.
We can't use existing max_allowed_packet parameter for this purpose
since its value is limited by 1GB and therefore using it as a limit
for data set through mysql_send_long_data() API would have been an
incompatible change. Newly introduced max_long_data_size parameter
gets value from max_allowed_packet parameter unless its value is
specified explicitly. This new parameter is marked as deprecated
and will be eventually replaced by max_allowed_packet parameter.
Value of max_long_data_size parameter can be set only at server
startup.
mysql-test/t/variables.test:
Added checking for new start-up parameter max_long_data_size.
sql/item.cc:
Added call to my_message() when accumulated string exceeds
max_long_data_size value. my_message() calls error handler
that was installed in mysql_stmt_get_longdata before call
to Item_param::set_longdata.
The error handler then sets state, last_error and last_errno
fields for current statement to values which correspond to
error which was caught.
sql/mysql_priv.h:
Added max_long_data_size variable declaration.
sql/mysqld.cc:
Added support for start-up parameter 'max_long_data_size'.
This parameter limits size of data which can be sent from
client to server using mysql_send_long_data() API.
sql/set_var.cc:
Added variable 'max_long_data_size' into list of variables
displayed by command 'show variables'.
sql/sql_prepare.cc:
Added error handler class Set_longdata_error_handler.
This handler is used to catch any errors that can be
generated during execution of Item_param::set_longdata().
Source code snippet that makes checking for statement's state
during statement execution is moved from Prepared_statement::execute()
to Prepared_statement::execute_loop() in order not to call
set_parameters() when statement has failed during
set_long_data() execution. If this hadn't been done
the call to set_parameters() would have failed.
tests/mysql_client_test.c:
A testcase for the bug #56976 was added.
FAILED DROP DATABASE CAN BREAK STATEMENT BASED REPLICATION
The first phase of DROP DATABASE is to delete the tables in the database.
If deletion of one or more of the tables fail (e.g. due to a FOREIGN KEY
constraint), DROP DATABASE will be aborted. However, some tables could
still have been deleted. The problem was that nothing would be written
to the binary log in this case, so any slaves would not delete these tables.
Therefore the master and the slaves would get out of sync.
This patch fixes the problem by making sure that DROP TABLE is written
to the binary log for the tables that were in fact deleted by the failed
DROP DATABASE statement.
Test case added to binlog.binlog_database.test.
INSTALLATION
When starting mysqld as an MS Windows NT service, it crashed
with "Error 1067: The process terminated unexpectedly".
The problem is that thread local variables are not allocated
and initialized properly when started as a service. When the
server is started as a regular executable, the problem does
not occur.
Analysis showed that this is a regression after the patch for
Bug#11765237/Bug#11763065. Before, the thread local storage
was initialized by the call chain:
win_main->my_basic_init->my_thread_basic_global_init->
my_thread_init
When the my_init() structure was changed, this initialization
was moved from win_main to mysqld_main. When started as
a service win_main is run in a separate thread, which does
not have mysqld_main in its call path, so my_thread_init
is never called for this thread.
Added a call to my_thread_init / my_thread_end in the service
handler function, which solves the problem.
pre-locking list caused by triggers).
The thing is that CREATE TRIGGER / DROP TRIGGER may actually
change pre-locking list of (some) stored routines.
The SP-cache does not detect such changes. Thus if sp_head-instance
is cached in SP-cache, subsequent executions of the cached
sp_head will use inaccurate pre-locking list.
The patch is to invalidate SP-cache on CREATE TRIGGER / DROP TRIGGER.
MAP 'REPAIR TABLE' TO RECREATE +ANALYZE FOR ENGINES NOT
SUPPORTING NATIVE REPAIR
Executing 'mysqlcheck --check-upgrade --auto-repair ...' will first issue
'CHECK TABLE FOR UPGRADE' for all tables in the database in order to check if the
tables are compatible with the current version of MySQL. Any tables that are
found incompatible are then upgraded using 'REPAIR TABLE'.
The problem was that some engines (e.g. InnoDB) do not support 'REPAIR TABLE'.
This caused any such tables to be left incompatible. As a result such tables were
not properly fixed by the mysql_upgrade tool.
This patch fixes the problem by first changing 'CHECK TABLE FOR UPGRADE' to return
a different error message if the engine does not support REPAIR. Instead of
"Table upgrade required. Please do "REPAIR TABLE ..." it will report
"Table rebuild required. Please do "ALTER TABLE ... FORCE ..."
Second, the patch changes mysqlcheck to do 'ALTER TABLE ... FORCE' instead of
'REPAIR TABLE' in these cases.
This patch also fixes 'ALTER TABLE ... FORCE' to actually rebuild the table.
This change should be reflected in the documentation. Before this patch,
'ALTER TABLE ... FORCE' was unused (See Bug#11746162)
Test case added to mysqlcheck.test
client/mysqlcheck.c:
Changed mysqlcheck to do 'ALTER TABLE ... FORCE' if
'CHECK TABLE FOR UPGRADE' reports ER_TABLE_NEEDS_REBUILD
and not ER_TABLE_NEEDS_UPGRADE.
mysql-test/r/mysqlcheck.result:
Added regression test.
mysql-test/std_data/bug47205.frm:
InnoDB 5.0 FRM which contains a varchar primary key using
utf8_general_ci. This is an incompatible FRM for 5.5.
mysql-test/t/mysqlcheck.test:
Added regression test.
sql/handler.h:
Added new HA_CAN_REPAIR flag.
sql/share/errmsg-utf8.txt:
Added new error message ER_TABLE_NEEDS_REBUILD
sql/sql_admin.cc:
Changed 'CHECK TABLE FOR UPDATE' to give ER_TABLE_NEEDS_REBUILD
instead of ER_TABLE_NEEDS_UPGRADE if the engine does not support
REPAIR (as indicated by the new HA_CAN_REPAIR flag).
sql/sql_lex.h:
Remove unused ALTER_FORCE flag.
sql/sql_yacc.yy:
Make sure ALTER TABLE ... FORCE recreates the table
by setting the ALTER_RECREATE flag as the ALTER_FORCE
flag was unused.
storage/archive/ha_archive.h:
Added new HA_CAN_REPAIR flag to Archive
storage/csv/ha_tina.h:
Added new HA_CAN_REPAIR flag to CSV
storage/federated/ha_federated.h:
Added new HA_CAN_REPAIR flag to Federated
storage/myisam/ha_myisam.cc:
Added new HA_CAN_REPAIR flag to MyISAM
