The subtime function wasn't able to produce correct int representation of
its result. For constant expressions the Item_datetime_cache is used to
speedup evaluation and Item_datetime_cache expects underlying item to return
correct int representation of DATETIME value. These two factors combined led
to a wrong query result.
Now the Item_func_add_time has function val_datetime which performs the
calculation and saves result into given MYSQL_TIME struct, it also sets
null_value to appropriate value. val_int and val_str member functions
convert the result obtained from val_datetime to int or string respectively
and returns it.
mysql-test/r/func_time.result:
Added a test case for the bug#57039.
mysql-test/t/func_time.test:
Added a test case for the bug#57039.
sql/item_timefunc.cc:
Bug#57039: constant subtime expression returns incorrect result.
Now the Item_func_add_time has function val_datetime which performs the
calculation and saves result into given MYSQL_TIME struct, it also sets
null_value to appropriate value. val_int and val_str member functions
convert the result obtained from val_datetime to int or string respectively
and returns it.
sql/item_timefunc.h:
Bug#57039: constant subtime expression returns incorrect result.
The fix is to:
- introduce ORACLE_WELCOME_COPYRIGHT_NOTICE define to have a single place
to specify copyright notice;
- replace custom copyright notices with ORACLE_WELCOME_COPYRIGHT_NOTICE
in programs.
Problem: CASE didn't work with a mixture of different character
sets in THEN/ELSE in some cases.
This happened because after character set aggregation
newly created Item_func_conv_charset items corresponding
to THEN/ELSE arguments were not put back to args[] array.
Fix:
put all Item_func_conv_charset back to args[].
@ mysql-test/include/ctype_numconv.inc
@ mysql-test/r/ctype_ucs.result
Adding tests
@ sql/item_cmpfunc.cc
Put "agg" back to args[] after character set aggregation.
Quoting from the bug report:
The pstack library has been included in MySQL since version
4.0.0. It's useless and should be removed.
Details: According to its own documentation, pstack only works
on Linux on x86 in 32 bit mode and requires LinuxThreads and a
statically linked binary. It doesn't really support any Linux
from 2003 or later and doesn't work on any other OS.
LOAD DATA into partitioned MyISAM table
Problem was that both partitioning and myisam
used the same table_share->mutex for different protections
(auto inc and repair).
Solved by adding a specific mutex for the partitioning
auto_increment.
Also adding destroying the ha_data structure in
free_table_share (which is to be propagated
into 5.5).
This is a 5.1 ONLY patch, already fixed in 5.5+.
REBUILD PARTITION under LOCK TABLE
Collapsed patch including updates from the reviews.
In case of failure in ALTER ... PARTITION under LOCK TABLE
the server could crash, due to it had modified the locked
table object, which was not reverted in case of failure,
resulting in a bad table definition used after the failed
command.
Solved by instead of altering the locked table object and
its partition_info struct, creating an internal temporary
intermediate table object used for altering,
just like the non partitioned mysql_alter_table.
So if an error occur before the alter operation is complete,
the original table is not modified at all.
But if the alter operation have succeeded so far that it
must be completed as whole,
the table is properly closed and reopened.
(The completion on failure is done by the ddl_log.)
mysql-test/suite/parts/inc/partition_fail.inc:
Added tests under LOCK TABLE
mysql-test/suite/parts/r/partition_debug_innodb.result:
Updated results
mysql-test/suite/parts/r/partition_debug_myisam.result:
Updated results
mysql-test/suite/parts/r/partition_special_innodb.result:
updated result
mysql-test/suite/parts/t/partition_special_innodb.test:
changing comment, since this patch also fixes this.
sql/sql_partition.cc:
Added TODO, to use DBUG_SUICIDE() instead of abort()
to avoid core-files on expected crashes.
Removed unused arguments to fast_end_partition.
Opening a intermediate table in prep_alter_part_table, instead of altering
(a possible locked) normally opened table.
That way we do not have to do anything more than close
the intermediate table on error,
leaving the ordinary table opened and locked.
Also making sure that the intermediate table are
closed/destroyed on failure. If no error occur
it is later destroyed in the end of fast_alter_partition_table.
Added ha_external_lock to make sure MyISAM flushed the index file
after copying the partitions.
This also leads to removal of the special close and removal from
the table cache for other instances of the table.
sql/sql_partition.h:
Changed the arguments for prep_alter_part_table and
fast_alter_partition_table to use an intermediate table
instead of altering a (possibly locked) normal table.
sql/sql_table.cc:
Using an intermediate table created in prep_alter_part_table
to be used in fast_alter_partition_table, also closing/destroying
it on failure.
Bug#57113: ha_partition::extra(ha_extra_function):
Assertion `m_extra_cache' failed
Fix for bug#55458 included DBUG_ASSERTS causing
debug builds of the server to crash on
another multi-table update.
Removed the asserts since they where wrong.
(updated after testing the patch in 5.5).
mysql-test/r/partition.result:
updated result
mysql-test/t/partition.test:
Added test for bug#57113
sql/ha_partition.cc:
Removed the assert for m_extra_cache when
::extra(HA_PREPARE_FOR_UPDATE) was called.
argument of inline_mysql_mutex_init in sql_base.cc.
When initializing LOCK_dd_owns_lock_open mutex pass
correct PSI key instead of NULL value.
mysql-test/suite/perfschema/r/dml_setup_instruments.result:
Updated test results after adding P_S instrumentation
for LOCK_dd_owns_lock_open.
sql/sql_base.cc:
When initializing LOCK_dd_owns_lock_open mutex pass
correct PSI key instead of NULL value.
After the patch for Bug#54579, multi inserts done with INSERT DELAYED
are binlogged as normal INSERT. During processing of the statement,
a new query string without the DELAYED keyword is made. The problem
was that this new string was incorrectly made when the INSERT DELAYED
was part of a prepared statement - data was read outside the allocated
buffer.
The reason for this bug was that a pointer to the position of the
DELAYED keyword inside the query string was stored when parsing the
statement. This pointer was then later (at runtime) used (via pointer
subtraction) to find the number of characters to skip when making a
new query string without DELAYED. But when the statement was re-executed
as part of a prepared statement, the original pointer would be invalid
and the pointer subtraction would give a wrong/random result.
This patch fixes the problem by instead storing the offsets from the
beginning of the query string to the start and end of the DELAYED
keyword. These values will not depend on the memory position
of the query string at runtime and therefore not give wrong results
when the statement is executed in a prepared statement.
This bug was a regression introduced by the patch for Bug#54579.
No test case added as this bug is already covered by the existing
binlog.binlog_unsafe test case when running with valgrind.
but broken.
Before this patch, it was allowed to use stored functions in
HANDLER ... READ statements. The problem was that this functionality
was not really supported by the code. Proper locking would for example
not be performed, and it was also possible to break replication by
having stored functions that performed updates.
This patch disallows the use of stored functions in HANDLER ... READ.
Any such statement will now give an ER_NOT_SUPPORTED_YET error.
This is an incompatible change and should be reflected in the
documentation.
Test case added to handler_myisam/handler_innodb.test.
Fixed a number of memory leaks discovered by valgrind.
dbug/dbug.c:
This is actually an addendum to the fix for bug #52629:
- there is no point in limiting the fix to just global
variables, session ones are also affected.
- zero all fields when allocating a new 'state' structure so
that FreeState() does not deal with unitialized data later.
- add a check for a NULL pointer in DBUGCloseFile()
mysql-test/r/partition_error.result:
Added a test case for bug #56709.
mysql-test/r/variables_debug.result:
Added a test case for bug #56709.
mysql-test/t/partition_error.test:
Added a test case for bug #56709.
mysql-test/t/variables_debug.test:
Added a test case for bug #56709.
sql/item_timefunc.cc:
There is no point in declaring 'value' as a member of
Item_extract and dynamically allocating memory for it in
Item_extract::fix_length_and_dec(), since this string is only
used as a temporary storage in Item_extract::val_int().
sql/item_timefunc.h:
Removed 'value' from the Item_extract class definition.
sql/sql_load.cc:
- we may need to deallocate 'buffer' even when 'error' is
non-zero in some cases, since 'error' is public, and there is
external code modifying it.
- assign NULL to buffer when deallocating it so that we don't
do it twice in the destructor
- there is no point in changing 'error' in the destructor.
REPAIR of merge table
Bug #56422 CHECK TABLE run when the table is locked reports
corruption along with timeout
The crash happened if a table maintenance statement (ANALYZE TABLE,
REPAIR TABLE, etc.) was executed on a MERGE table and opening and
locking a child table failed. This could for example happen if a child
table did not exist or if a lock timeout happened while waiting for
a conflicting metadata lock to disappear.
Since opening and locking the MERGE table and its children failed,
the tables would be closed and the metadata locks released.
However, TABLE_LIST::table for the MERGE table would still be set,
with its value invalid since the tables had been closed.
This caused the table maintenance statement to try to continue
and upgrade the metadata lock on the MERGE table. But since the lock
already had been released, this caused a segfault.
This patch fixes the problem by setting TABLE_LIST::table to NULL
if open_and_lock_tables() fails. This prevents maintenance
statements from continuing and trying to upgrade the metadata lock.
The patch includes a 5.5 version of the fix for
Bug #46339 crash on REPAIR TABLE merge table USE_FRM.
This bug caused REPAIR TABLE ... USE_FRM to give an assert
when used on merge tables.
The patch also enables the CHECK TABLE statement for log tables.
Before, CHECK TABLE for log tables gave ER_CANT_LOCK_LOG_TABLE,
yet still counted the statement as successfully executed.
With the changes to table maintenance statement error handling
in this patch, CHECK TABLE would no longer be considered as
successful in this case. This would have caused upgrade scripts
to mistakenly think that the general and slow logs are corrupted
and have to be repaired. Enabling CHECK TABLES for log tables
prevents this from happening.
Finally, the patch changes the error message from "Corrupt" to
"Operation failed" for a number of issues not related to table
corruption. For example "Lock wait timeout exceeded" and
"Deadlock found trying to get lock".
Test cases added to merge.test and check.test.
Fixed incorrect handling of user credentials when authenticating
via proxy user. Now the server will use the proxies user's
access mask and host to update the security context runtime
structure when logging in.
Fixed a compilation warning with the embedded library.
Fixed a crash when doing a second GRANT PROXY on ''@'' due to
incomplete equality check logic.
Subselect executes twice, at JOIN::optimize stage
and at JOIN::execute stage. At optimize stage
Innodb prebuilt struct which is used for the
retrieval of column values is initialized in.
ha_innobase::index_read(), prebuilt->sql_stat_start is true.
After QUICK_ROR_INTERSECT_SELECT finished his job it
restores read_set/write_set bitmaps with initial values
and deactivates one of the handlers used by
QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup
(it's the case when we reuse original handler as one of
handlers required by QUICK_ROR_INTERSECT_SELECT object).
On second subselect execution inactive handler is activated
in QUICK_RANGE_SELECT::reset, file->ha_index_init().
In ha_index_init Innodb prebuilt struct is reinitialized
with inappropriate read_set/write_set bitmaps. Further
reinitialization in ha_innobase::index_read() does not
happen as prebuilt->sql_stat_start is false.
It leads to partial retrieval of required field values
and we get a mix of field values from different records
in the record buffer.
The fix is to reset
read_set/write_set bitmaps as these values
are required for proper intialization of
internal InnoDB struct which is used for
the retrieval of column values
(see build_template(), ha_innodb.cc)
mysql-test/include/index_merge_ror_cpk.inc:
test case
mysql-test/r/index_merge_innodb.result:
test case
mysql-test/r/index_merge_myisam.result:
test case
sql/opt_range.cc:
if ROR merge scan is used we need to reset
read_set/write_set bitmaps as these values
are required for proper intialization of
internal InnoDB struct which is used for
the retrieval of column values
(see build_template(), ha_innodb.cc)
adding new indexes
A fast alter table requires that the existing (old) table
and indices are unchanged (i.e only new indices can be
added). To verify this, the layout and flags of the old
table/indices are compared for equality with the new.
The PACK_KEYS option is a no-op in InnoDB, but the flag
exists, and is used in the table compare. We need to
check this (table) option flag before deciding whether an
index should be packed or not. If the table has
explicitly set PACK_KEYS to 0, the created indices should
not be marked as packed/packable.
