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.
mysql-test/r/errors.result:
Test case relied on system variable that is only available if
replication is compiled in. Replaced with variable available in
all builds.
mysql-test/t/errors.test:
Test case relied on system variable that is only available if
replication is compiled in. Replaced with variable available in
all builds.
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.
mysql-test/r/errors.result:
Add test for BUG#57882
mysql-test/t/errors.test:
Add test for BUG#57882
sql/item.cc:
Make agg_item_set_converter() return with error if fix_fields()
on the newly created converted item fails.
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.
mysql-test/r/func_time.result:
Test case for bug #52160.
mysql-test/r/type_blob.result:
Test case for bug #52160.
mysql-test/t/func_time.test:
Test case for bug #52160.
mysql-test/t/type_blob.test:
Test case for bug #52160.
sql/item_timefunc.h:
Bug #52160: crash and inconsistent results when grouping
by a function and column
TIME_TO_SEC() returns NULL if its argument is invalid (empty
string for example). Thus its nullability depends not only
Fixed by (overoptimistically) setting TIME_TO_SEC() to be
nullable despite the nullability of its arguments.
sql/sql_select.cc:
Bug #52160: crash and inconsistent results when grouping
by a function and column
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.
client/mysqlbinlog.cc:
Give a warning for --base64-output=always and --base64-output,
and print warning in mysqlbinlog --help.
mysql-test/r/mysqlbinlog.result:
updated result file
mysql-test/t/mysqlbinlog.test:
Test that mysqlbinlog --base64-output=always gives a warning.
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.
main.mysqltest skipped on Windows because a perl intentionally does exit(1)
Use exit(2), as exit(1) on Windows is indistinguishable from failing to
execute perl.
data dictionary confusion
On file systems with case insensitive file names, and
lower_case_table_names set to '2', the server could crash
due to a table definition cache inconsistency. This is
the default setting on MacOSX, but may also be set and
used on MS Windows.
The bug is caused by using two different strategies for
creating the hash key for the table definition cache, resulting
in failure to look up an entry which is present in the cache,
or failure to delete an existing entry. One strategy was to
use the real table name (with case preserved), and the other
to use a normalized table name (i.e a lower case version).
This is manifested in two cases. One is during 'DROP DATABASE',
where all known files are removed. The removal from
the table definition cache is done via a generated list of
TABLE_LIST with keys (wrongly) created using the case preserved
name. The other is during CREATE TABLE, where the cache lookup
is also (wrongly) based on the case preserved name.
The fix was to use only the normalized table name when
creating hash keys.
sql/sql_db.cc:
Normalize table name (i.e lower case it)
sql/sql_table.cc:
table_name contains the normalized name
alias contains the real table name
After the fix for
Bug #55077 Assertion failed: width > 0 && to != ((void *)0), file .\dtoa.c
we no longer try to allocate a string of length 'field_length'
so the asserts are relevant only for ZEROFILL columns.
mysql-test/r/select.result:
Add test case for Bug#57203
mysql-test/t/select.test:
Add test case for Bug#57203
sql/field.cc:
Rewrite the DBUG_ASSERTS on field_length.
sql_show.cc during rqg_info_schema test on Windows".
Ensure we do not access freed memory when filling
information_schema.views when one of the views
could not be properly opened.
mysql-test/r/information_schema.result:
Update results - a fix for Bug#56540.
mysql-test/t/information_schema.test:
Add a test case for Bug#56540
sql/sql_base.cc:
Push an error into the Diagnostics area
when we return an error.
This directs get_all_tables() to the execution
branch which doesn't involve 'process_table()'
when no table/view was opened.
sql/sql_show.cc:
Do not try to access underlying table fields
when opening of a view failed. The underlying
table is closed in that case, and accessing
its fields may lead to dereferencing a damaged
pointer.
thd->in_sub_stmt || (thd->state..
OPTIMIZE TABLE is not directly supported by InnoDB. Instead,
recreate and analyze of the table is done. After recreate,
the table is closed and locks are released before the table
is reopened and locks re-acquired for the analyze phase.
This assertion was triggered if OPTIMIZE TABLE failed to
acquire thr_lock locks before starting the analyze phase.
The assertion tests (among other things) that there no
active statement transaction. However, as part of acquiring
the thr_lock lock, external_lock() is called for InnoDB
tables and this causes a statement transaction to be started.
If thr_multi_lock() later fails (e.g. due to timeout),
the failure handling code causes this assert to be triggered.
This patch fixes the problem by doing rollback of the
current statement transaction in case open_ltable (used by
OPTIMIZE TABLE) fails to acquire thr_lock locks.
Test case added to lock_sync.test.
mysql-test/r/grant.result:
It was added result for test case for bug#36742.
mysql-test/t/grant.test:
It was added test case for bug#36742.
sql/sql_yacc.yy:
It was added convertation of host name part of user name to lowercase.
Only wait for a single debug signal at a time as the signal state
is global. Also, do not activate the query cache debug sync points
if the thread has no associated THD session.
mysql-test/t/query_cache_debug.test:
Only wait for a single debug signal at a time as the signal state
is global.
sql/sql_cache.cc:
Do not execute the debug sync point if the thread has no associated
THD session. This scenario happens for federated threads.
Buffer overrun when trying to format DBL_MAX
mysql-test/r/func_math.result:
Add test case for Bug#57209
mysql-test/t/func_math.test:
Add test case for Bug#57209
sql/item_strfunc.cc:
Allocate a larger buffer for the result.
Issue an error if user specifies multiple commands to run.
Also there was an unnoticed bug that DO_CHECK was actually 0 which lead
to wrong actions in some cases.
The mysqlcheck.test contained commands with the suspicious meaning
for the above reason. Extra commands removed from there.
per-file commands:
client/mysqlcheck.c
Bug#35269 mysqlcheck behaves different depending on order of parameters
Drop with an error if multiple commands.
mysql-test/r/mysqlcheck.result
Bug#35269 mysqlcheck behaves different depending on order of parameters
result completed.
mysql-test/t/mysqlcheck.test
Bug#35269 mysqlcheck behaves different depending on order of parameters
testcase added.
not-working commands removed from some mysqlcheck calls.
The problem was that threads waiting on the query cache lock
are not easily seen due to the lack of a state indicating that
the thread is waiting on the said lock. This made it difficult
for users to quickly spot (for example, via SHOW PROCESSLIST)
a query cache contention problem.
The solution is to update the thread state when the query cache
lock needs to be acquired. Whenever the lock is to be acquired,
the thread state is updated to "Waiting for query cache lock"
and is reset once the lock is granted or the wait is interrupted.
The intention is to make query cache related hangs more evident.
To further investigate query cache related locking problems, one
may use PERFORMANCE_SCHEMA to track the overhead associated with
the locking bits and determine which particular lock is being a
contention point.
sql/sql_cache.cc:
Set and reset the thread state whenever a attempt to lock the
query cache is made.
Use DEBUG_SYNC instead of the now unnecessary wait_for_kill hack.
The coalesce function returned DATETIME type due to a DATETIME argument, but
since it's not a date/time function it can't return correct int value for
it. Nevertheless Item_datetime_cache was chosen to cache coalesce's result
and that led to a wrong result.
Now Item_datetime_cache is used only for those function that could return
correct int representation of DATETIME values.
mysql-test/r/type_datetime.result:
Added a test case for the bug#57095.
mysql-test/t/type_datetime.test:
Added a test case for the bug#57095.
sql/item.cc:
Bug#57095: Wrongly chosen expression cache type led to a wrong result.
Now Item_datetime_cache is used only for those function that could return
correct int representation of DATETIME values.
discover its existence".
The problem was that user without any privileges on
routine was able to find out whether it existed or not.
DROP FUNCTION and DROP PROCEDURE statements were
checking if routine being dropped existed and reported
ER_SP_DOES_NOT_EXIST error/warning before checking
if user had enough privileges to drop it.
This patch solves this problem by changing code not to
check if routine exists before checking if user has enough
privileges to drop it. Moreover we no longer perform this
check using a separate call instead we rely on
sp_drop_routine() returning SP_KEY_NOT_FOUND if routine
doesn't exist.
This change also simplifies one of upcoming patches
refactoring global read lock implementation.
mysql-test/r/grant.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence". Removed
DROP PROCEDURE/FUNCTION statements which have started to
fail after this fix (correctly). There is no need in
dropping routines in freshly created database anyway.
mysql-test/r/sp-security.result:
Added new test case for bug#57061 "User without privilege
on routine can discover its existence". Updated existing
tests according to new behaviour.
mysql-test/suite/funcs_1/r/innodb_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/r/memory_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/r/myisam_storedproc_06.result:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/suite/funcs_1/storedproc/storedproc_06.inc:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence".
Now we drop routines under user which has enough
privileges to do so.
mysql-test/t/grant.test:
Updated test case after fixing bug#57061 "User without
privilege on routine can discover its existence". Removed
DROP PROCEDURE/FUNCTION statements which have started to
fail after this fix (correctly). There is no need in
dropping routines in freshly created database anyway.
mysql-test/t/sp-security.test:
Added new test case for bug#57061 "User without privilege
on routine can discover its existence". Updated existing
tests according to new behaviour.
sql/sp.cc:
Removed sp_routine_exists_in_table() which is no longer
used.
sql/sp.h:
Removed sp_routine_exists_in_table() which is no longer
used.
sql/sql_parse.cc:
When dropping routine we no longer check if routine exists
before checking if user has enough privileges to do so.
Moreover we no longer perform this check using a separate
call instead we rely on sp_drop_routine() returning
SP_KEY_NOT_FOUND if routine doesn't exist.
