The convert_constant_item function converts a constant to integer using
field for condition like 'field = a_constant'. In some cases the
convert_constant_item is called for a subquery when outer select is already
being executed, so convert_constant_item saves field's value to prevent its
corruption. For EXPLAIN and at the prepare phase field's value isn't
initialized yet, thus when convert_constant_item tries to restore saved
value it fails assertion.
Now the convert_constant_item doesn't save/restore field's value if it's
haven't been read yet. Outer constant values are always saved.
Bug#39848 events_bugs fails sporadically on pushbuild
(missing rows in table event_log)
Details: Reimplement the subtest for BUG 28924
- check if the number of rows within the table
event_log changes but don't print rows
because the number varies depending on
load on testing box
- shift DROP USER befor DROP EVENT
= Subtest fits again to old bug
- remove no more needed comments + variables
Bug#39863 events_bugs fails sporadically on pushbuild
(extra processes in I_S.PROCESSLIST)
Details: Abort with appropriate message to the protocol if
release_lock() does not has the intended effect.
This cannot prevent problems caused by the probably
buggy release_lock() but it reveals if we had a
problem in this area.
Bug#39978 main.events_bugs does not clean up
Detail: Restore global.event_scheduler = ON at end of test
Bug#39569 events_bugs fails sporadically on pushbuild
(should have failed with errno 1539)
Detail: Set $wait_timeout to 4 instead of 2
- Fix two instabilities (result sets pulled from processlist in
subtest for bug 16407) which were found during tests with high
parallel I/O load
- Minor improvements of formatting
Details:
- Add comments
- Remove tabs and trailing blanks
- Add line breaks for better readability
The partitioning clause is only a very long single line, which is very
hard to interpret for a human. This patch breaks the partitioning
syntax into one line for the partitioning type, and one line per
partition/subpartition.
Problem was that partitioning cached the table flags.
These flags could change due to TRANSACTION LEVEL changes.
Solution was to remove the cache and always return the table flags
from the first partition (if the handler was initialized).
#ifdef HAVE_purify removed
per-file comments:
mysql-test/t/partition_not_windows.test
Bug#39102 valgrind build does not compile in realpath, which make DATA/INDEX DIR fail
test reenabled
mysys/my_symlink.c
Bug#39102 valgrind build does not compile in realpath, which make DATA/INDEX DIR fail
superfluous ifdef removed, comments fixed
A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries
The convert_constant_item function converts a constant to integer using
field for condition like 'field = a_constant'. When the convert_constant_item
is called for a subquery the outer select is already being executed, so
convert_constant_item saves field's value to prevent its corruption.
For EXPLAIN field's value isn't initialized thus when convert_constant_item
tries to restore saved value it fails assertion.
Now the convert_constant_item doesn't save/restore field's value
for EXPLAIN.
Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.
Fix: reinsert data altering an enum field if enum values are changed.
- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1
breaks auto increment
The auto_increment value was not initialized if
the first statement after opening a table was
an 'UPDATE'.
solution was to check initialize if it was not,
before trying to increase it in update.
The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.
The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.
fails after the first time
Two separate problems :
1. When flattening joins the linked list used for name resolution
(next_name_resolution_table) was not updated.
Fixed by updating the pointers when extending the table list
2. The items created by expanding a * (star) as a column reference
were marked as fixed, but no cached table was assigned to them
(unlike what Item_field::fix_fields does).
Fixed by assigning a cached table (so the re-preparation is done
faster).
Note that the fix for #2 hides the fix for #1 in most cases
(except when a table reference cannot be cached).
