sql_print_warning() and sql_print_error() instead of fprintf to stderr.
Above functions are tuned for different platforms so that the behavior
is consistent around platforms. Using fprintf() different behavior can
be expected at least on Windows and Unix.
subqry order by server crash": failing DBUG_ASSERT(curr_join == this)
when opening a cursor.
Ensure that for top-level join curr_join == join (always),
and thus fix the failing assert.
curr_join is a hack to ensure that uncacheable subqueries can be
re-evaluated safely, and should be never different from main join
in case of top-level join.
cause crash on update".
Let us update "thd" pointer in LEX, all its units and in LEX::result before
executing statement in trigger body, since triggers are associated with TABLE
object and because of this can be used in different threads.
When PRIMARY KEY is present ha_innobase::cmp_ref() uses it to compare refs.
After comparing part of key it moves pointers to compare next part.
For varchar parts pointers were moved only by length of parts, not including
bytes containig part length itself. This results in wrong comparision and
wrong number of deleted records.
Added a test case for bug #12392.
item_cmpfunc.cc:
Fixed bug #12392.
Missing handling of rows containing NULL components
when evaluating IN predicates caused a crash.
* Cleanup SP Cache code, now SP Cache only deletes sp_head objects in
sp_cache_flush_obsolete() invalidates all pointers to routines in the cache.
* Use new SP Cache use contract in the code.
There is no test case because it doesn't seem to be possible to cause thread races to end
the same way they end in heavy-load test. This patch removes the crash in heavy test.
- Fixed some error condtion when handling dates with 'T'
- Added extra test for bug #11867 (Wrong result with "... WHERE ROW( a, b ) IN ( SELECT DISTINCT a, b WHERE ...)" to show it's not yet fixed
- Safety fixes and cleanups
BUG #11104
Took out the offset-=delimiter_length-1 out of the for loop. It was causing
basically this:
select substring_index('the king of the the hill', 'the', -2) to not work.
The first iteration, offset would be initialised to 24, then strstr would
point at 'the king of the the* hill' ('*'means right before the
character following), returning a offset of 16. The for loop would then
decrement offset by two (3 - 1), to 14, now pointing at
"the king of th*e the hill", _skipping_ past the 'e' in the second to last
'the', and therefore strstr would never have a chance of matching the
second to last 'the', then moving on to the 'the' at the begginning of the
string!
In a nutshell, offset was being decremented by too great a value, preventing
the second to last 'the' from being ever found, hence the result of
'king of the the hill' from the query that is reported in the bug report
func_str.test:
BUG #11104
Added tests to make sure fix addresses issues in original bug report
func_str.result:
BUG #11104
New results for new tests
result set".
To enable full access to contents of I_S tables from stored functions
or statements that use them, we manipulate with thread's open tables
state and ensure that we won't cause deadlock when we open tables by
ignoring flushes and name-locks.
Building of contents of I_S.TABLES no longer requires locking of tables
since we use use handler::info() method with HA_STATUS_AUTO flag instead
of handler::update_auto_increment() for obtaining information about
auto-increment values. But this also means that handlers have to implement
support for HA_STATUS_AUTO flag (particularly InnoDB needs it).
