The problem is that since MyISAM's concurrent_insert is on by
default some concurrent SELECT statements might not see changes
made by INSERT statements in other connections, even if the
INSERT statement has returned.
The solution is to disable concurrent_insert so that INSERT
statements returns after the data is actually visible to other
statements.
When concurrent inserts were disabled, statements after an INSERT
were not put into the query cache. This happened because we do not
save the current data file length at statement start when
concurrent inserts are disabled. But we checked the always zero
local length against the real file length anyway.
Fixed by doing the check only if concurrent inserts are not diabled.
table with backticks
(Thanks to Lu Jingdong, though I did not take his patch directly, as
it contained a significant flaw.)
It wasn't a backtick/parsing problem. We merely didn't anticipate
and allocate enough space to handle the optional "#mysql50#" table-
name prefix.
Now, allocate that extra space in case we need it when we look up
a legacy table to get its file's name.
than max_connections -- which results in user lockout.
The problem was that the variable thread_count that contains
the number of active threads was interpreted as a number of
active connections.
The fix is to introduce a new counter for active connections.
In cases when TRUNCATE was executed by invoking mysql_delete() rather
than by table recreation (for example, when TRUNCATE was issued on
InnoDB table with is referenced by foreign key) triggers were invoked.
In debug builds this also led to crash because of an assertion, which
assumes that some preliminary actions take place before trigger
invocation, which doesn't happen in case of TRUNCATE.
The fix is not to execute triggers in mysql_delete() when this
function is used by TRUNCATE.
ChangeSet@1.2565, 2008-03-11 20:20:49+01:00
Merge five.local.lan:/work/merge/mysql-5.0-funcs_1
into five.local.lan:/work/merge/mysql-5.1-funcs_1
MERGE: 1.1810.3473.26
ChangeSet@1.1810.3473.26, 2008-03-11 19:54:35+01:00
Post fix for
WL#4203 Reorganize and fix the data dictionary tests of
testsuite funcs_1
The final fix of
Bug#34532 Some funcs_1 tests do not clean up at end of testing
and some minor additional modifications are for
happens here
WL#4203 Reorganize and fix the data dictionary tests of
testsuite funcs_1
because the goal to fix
Bug#34532 Some funcs_1 tests do not clean up at end of testing
was partially missed.
Some minor additional modifications are for
WL#4304 Cleanup in funcs_1 tests
Problem: rpl_variables_stm.test used a character set and a collation which
are not included on all platforms.
Fix: replace the character set and collation by ones that are included on
all platforms. (rpl_variables_stm does not rely on which character set is
used, the only important aspect is the fact that it changes.)
The reason is that we are using a sleep to wait for slave to reach the
slave_transaction_retries limit.
Fix: wait for the slave to stop instead. This is what we want to do, since
the slave stops when the limit is reached.
WHERE f1 < n ignored row if f1 was indexed integer column and
f1 = TYPE_MAX ^ n = TYPE_MAX+1. The latter value when treated
as TYPE overflowed (obviously). This was not handled, it is now.
ChangeSet@1.2561, 2008-03-07 17:44:03+01:00, mleich@five.local.lan +132 -0
Merge five.local.lan:/work/merge/mysql-5.0-funcs_1
into five.local.lan:/work/merge/mysql-5.1-funcs_1
MERGE: 1.1810.3473.24
ChangeSet@1.1810.3473.24, 2008-03-07
WL#4203 Reorganize and fix the data dictionary tests of
testsuite funcs_1
1. Adjustment of expected results to modified server properties
2. Add some tests of information_schema views
3. Minor corrections and improvements
Affected tests fixing. After the fix for st_relay_log_info::wait_for_pos() that
handles widely used select('master-bin.xxxx',pos) invoked by mysqltest
there appeared to be four tests that either tried synchronizing when
the slave was stopped or used incorrect synchronization method like
to call `sync_with_master' from the current connection being to the
master itself.
Fixed with correcting the current connection or/and using the correct
synchronization macro when possible.
Leopard.
The change_user test failed because results of some statements
depended on platform and server build flags.
subselect_notembedded failure was a result of a bad merge from 5.0.
Fixed the corresponding test cases.
testsuite funcs_1
1. Fix the following bugs
Bug#30440 "datadict" tests (all engines) fail: Character sets depend on configuration
Solution: Test variants charset_collation_* adjusted to different builds
Bug#32603 "datadict" tests (all engines) fail in "community" tree: "PROFILING" table
Solution: Excluding "PROFILING" table from queries
Bug#33654 "slow log" is missing a line
Solution: Unify the content of the fields TABLES.TABLE_ROWS and
STATISTICS.CARDINALITY within result sets
Bug#34532 Some funcs_1 tests do not clean up at end of testing
Solution: DROP objects/reset global server variables modified during testing
+ let tests missing implementation end before loading of tables
Bug#31421 funcs_1: ndb__datadict fails, discrepancy between scripts and expected results
Solution: Cut <engine>__datadict tests into smaller tests + generate new results.
Bug#33599 INFORMATION_SCHEMA.STATISTICS got a new column INDEX_COMMENT: tests fail (2)
Generation of new results during post merge fix
Bug#33600 CHARACTER_OCTET_LENGTH is now CHARACTER_MAXIMUM_LENGTH * 4
Generation of new results during post merge fix
Bug#33631 Platform-specific replace of CHARACTER_MAXIMUM_LENGTH broken by 4-byte encoding
Generation of new results during post merge fix
+ removal of platform-specific replace routine (no more needed)
2. Restructure the tests
- Test not more than one INFORMATION_SCHEMA view per testscript
- Separate tests of I_S view layout+functionality from content related to the
all time existing databases "information_schema", "mysql" and "test"
- Avoid storage engine related variants of tests which are not sensible to
storage engines at all.
3. Reimplement or add some subtests + cleanup
There is a some probability that even the reviewed changeset
- does not fix all bugs from above or
- contains new bugs which show up on some platforms <> Linux or on one of
the various build types
4. The changeset contains fixes according to
- one code review
- minor bugs within testing code found after code review (accepted by reviewer)
- problems found during tests with 5.0.56 in build environment
m_status == DA_OK
Reading from information_scema.tables or information_schema.columns
may cause assertion failure in debug builds. This may happen under
rare circumstances when information_schema fails to get information
about a table (e.g. when a connection is killed).
This happens because open_normal_and_derived_tables() can return an
error without setting an error message in THD. But information_schema
attempts to get an error message from THD unconditionally.
With this fix information_schema attempts to get an error message
from THD only in case error message is set in THD.
Problem: in mixed and statement mode, a query that refers to a
system variable will use the slave's value when replayed on
slave. So if the value of a system variable is inserted into a
table, the slave will differ from the master.
Fix: mark statements that refer to a system variable as "unsafe",
meaning they will be replicated by row in mixed mode and produce a warning
in statement mode. There are some exceptions: some variables are actually
replicated. Those should *not* be marked as unsafe.
BUG#34732: mysqlbinlog does not print default values for auto_increment variables
Problem: mysqlbinlog does not print default values for some variables,
including auto_increment_increment and others. So if a client executing
the output of mysqlbinlog has different default values, replication will
be wrong.
Fix: Always print default values for all variables that are replicated.
I need to fix the two bugs at the same time, because the test cases would
fail if I only fixed one of them.
There was a failure in that show slave status displayed a wrong message
when slave stopped at processing a row event inserting to a default-less
column.
The problem seem to have ceased after recent fixes in rbr code.
However, the test was not updated to carry testing of the case commented-out.
Uncommenting and editing the test.
Notice, Bug#23907 is most probably a duplicate of this one.
returns wrong results
Casting AVG() to DECIMAL led to incorrect results when the arguments
had a non-DECIMAL type, because in this case
Item_sum_avg::val_decimal() performed the division by the number of
arguments twice.
Fixed by changing Item_sum_avg::val_decimal() to not rely on
Item_sum_sum::val_decimal(), i.e. calculate sum and divide using
DECIMAL arithmetics for DECIMAL arguments, and utilize val_real() with
subsequent conversion to DECIMAL otherwise.
MASTER_POS_WAIT return values are different than expected when the server is not a slave.
It returns -1 instead of NULL.
Fixed with correcting st_relay_log_info::wait_for_pos() to return the proper
value in the case of rli info is not inited.
The initial value of free memory blocks in 0. When the query cache is enabled
a new memory block gets allocated and is assigned number 1. The free memory
block is later split each time query cache memory is allocated for new blocks.
This means that the free memory block counter won't be reduced to zero when
the number of allocated blocks are zero, but rather one. To avoid confusion
this patch changes this behavior so that the free memory block counter is
reset to zero when the query cache is disabled.
Note that when the query cache is enabled and resized the free memory block
counter was still calculated correctly.
The cause of the crash is an assertion failure that we do not emit
an error message (grant not found) and then return "ok". The
assertion is valid, and we were ignoring the buggy behavior prior
to the "Diagnostics" result-verification.
Use an error handler to mutate innocuous missing-grant errors, when
removing routines, into warnings.
There was no way to see if report-{host,port,user,password} were set up.
Fixed with introducing new global variables.
The variables are made read-only because of a possible need to change them
most probably require the slave server restart.
Todo: transform the startup options to be CHANGE master parameters - i.e
to deprecate `report-' options, and to change the new vars
to be updatable at time of CHANGE master executes with new
values.
It's impossible to determine which test inside mysql_client_test
failed if the log file is overwritten by mysqltest when dumping
the test case results. Redirect mysql_client_test output to a
separate file.
- Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
to before the late NULLs filtering code.
- Backport function comments from 6.0.
added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of mysql data home directory in
DATA DIRECTORY & INDEX DIRECTORY is disallowed.
Assertion `0' failed
If ROW item is a part of an expression that also has
aggregate function calls (COUNT/SUM/AVG...), a
"splitting" with an Item::split_sum_func2 function
is applied to that ROW item.
Current implementation of Item::split_sum_func2
replaces this Item_row with a newly created
Item_aggregate_ref reference to it.
Then the row cache tries to work with the
Item_aggregate_ref object as with the Item_row object:
row cache calls row-emulation methods such as cols and
element_index. Item_aggregate_ref (like it's parent
Item_ref) inherits dummy implementations of those
methods from the hierarchy root Item, and call to
them leads to failed assertions and wrong data
output.
Row-emulation virtual functions (cols, element_index, addr,
check_cols, null_inside and bring_value) of Item_ref have
been overloaded to forward calls to an underlying item
reference.
The problem is that passing anything other than a integer to a limit
clause in a prepared statement would fail. This limitation was introduced
to avoid replication problems (e.g: replicating the statement with a
string argument would cause a parse failure in the slave).
The solution is to convert arguments to the limit clause to a integer
value and use this converted value when persisting the query to the log.
NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was
not seen as constant, but as FUNCTION_UNARY_MINUS(constant)
while we are at the same time pretending it was a basic const
item. This confused the aggregate handlers in exciting ways.
We now make NAME_CONST() behave more consistently.
added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of 'mysql data home'/'any db name' in
DATA DIRECTORY & INDEX DIRECTORY is disallowed
Was a double-free of the Unique member of Item_func_group_concat.
This was not causing a crash because the Unique is a descendent of
Sql_alloc.
Fixed to free the Unique only if it was allocated for the instance
of Item_func_group_concat it was referenced from
Bug#34678 @@debug variable's incremental mode
The problem is that the per-thread debugging settings stack wasn't
being deallocated before the thread termination, leaking the stack
memory. The chosen solution is to push a new state if the current
is set to the initial settings and pop it (free) once the thread
finishes.
Fixed a missed case in the patch for Bug#31931.
Also makes Bug#33722 a duplicate of Bug#31931.
Added tests for better coverage.
Replaced some legacy function calls.
The problem is that the commands COM_STMT_CLOSE, COM_STMT_RESET,
COM_STMT_SEND_LONG_DATA weren't being logged to the general log.
The solution is to log the general log the aforementioned commands.
documentation
While the manual mentions FRAC_SECOND only for the TIMESTAMPADD()
function, it was also possible to use FRAC_SECOND with DATE_ADD(),
DATE_SUB() and +/- INTERVAL.
Fixed the parser to match the manual, i.e. using FRAC_SECOND for
anything other than TIMESTAMPADD()/TIMESTAMPDIFF() now produces a
syntax error.
Additionally, the patch allows MICROSECOND to be used in TIMESTAMPADD/
TIMESTAMPDIFF and marks FRAC_SECOND as deprecated.
If setting a system-variable provided by a plug-in failed, no OK or
error was sent in some cases, hanging the client. We now send an error
in the case from the ticket (integer-argument out of range in STRICT
mode). We also provide a semi-generic fallback message for possible
future cases like this where an error is signalled, but no message is
sent to the client. The error/warning handling is unified so it's the
same again for variables provided by plugins and those in the server
proper.
SQL-mode PAD_CHAR_TO_FULL_LENGTH affected mysqld's user-table too. If
enabled, user-name and host were space-padded and no longer matched
the login-data of incoming connexions.
Patch disregards pad-flag while loading privileges so ability to log
in does not depend on SQL-mode.
In BENCHMARK(count, expr), count could overflow/wrap-around.
Patch changes to a sufficiently large data-type. Adds a warning
for negative count values.
The check_global_access() function was made available to InnoDB, but
was not defined in the embedded server library. InnoDB, as a plugin,
is not recompiled when the embedded server is built. This caused a
link failure when compiling applications which use the embedded server.
The fix here is to always define check_global_access() externally; in
the embedded server case, it is defined to just return OK.
Also, don't run the test case for this bug in embedded server.
Disable extra team trees.
Temporary fix for entry 34761 in the bugs DB.
(Patch by Magnus Svensson, 2008-02-22 17:40:14+01:00, msvensson@pilot.mysql.com +1 -0)
log-slave-updates and circul repl
Slave SQL thread may execute one extra event when there are events
skipped by slave I/O thread (e.g. originated by the same server).
Whereas it was requested not to do so by the UNTIL condition.
This happens because we compare with the end position of previously
executed event. This is fine when there are no skipped by slave I/O
thread events, as end position of previous event equals to start
position of to be executed event. Otherwise this position equals to
start position of skipped event.
This is fixed by:
- reading the event to be executed before checking if the until condition
is satisfied.
- comparing the start position of the event to be executed. Since we do
not have the start position available, we compute it by subtracting
event length from end position (which is available).
- if there are no events on the event queue at the slave sql starting
time, that meet until condition, we stop immediately, as in this
case we do not want to wait for next event.
between 5.0 and 5.1.
The problem was that in the patch for Bug#11986 it was decided
to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
This approach however turned out to be quite difficult to implement
properly. The main problem is to preserve the same IS-output after
dump/restore.
So, the fix is to rollback to the previous functionality, but also
to fix it to support multi-character-set-queries properly. The idea
is to generate INFORMATION_SCHEMA-query from the item-tree after
parsing view declaration. The IS-query should:
- be completely in UTF8;
- not contain character set introducers.
For more information, see WL4052.
suite)
Under some circumstances a combination of aggregate functions and
GROUP BY in a SELECT query over a VIEW could lead to incorrect
calculation of the result type of the aggregate function. This in
turn could result in incorrect results, or assertion failures on debug
builds.
Fixed by changing the logic in Item_sum_hybrid::fix_fields() so that
the argument's item is dereferenced before calling its type() method.
The problem is that CREATE VIEW statements inside prepared statements
weren't being expanded during the prepare phase, which leads to objects
not being allocated in the appropriate memory arenas.
The solution is to perform the validation of CREATE VIEW statements
during the prepare phase of a prepared statement. The validation
during the prepare phase assures that transformations of the parsed
tree will use the permanent arena of the prepared statement.
a table name.
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
The fix is to ensure that an error is thrown even if the table
is in the cache.
(This is a backport of the original patch for 5.1)
"Server_IO_State" field
Critical error messages from get_master_version_and_clock() were written
only to the slave errorlog while Show slave status did not display any
incident happened.
Although the artifact was reported for a particular --replicate-same-server-id
related issue the fix refines all critical error reporting with
deploying rli->report().
The test for the bug covers only --replicate-same-server-id error reporting.
The problem is that when a stored procedure is being parsed for
the first execution, the body is copied to a temporary buffer
which is disregarded sometime after the statement is parsed.
And during this parsing phase, the rule for CREATE VIEW was
holding a reference to the string being parsed for use during
the execution of the CREATE VIEW statement, leading to invalid
memory access later.
The solution is to allocate and copy the SELECT of a CREATE
VIEW statement using the thread memory root, which is set to
the permanent arena of the stored procedure.
a table name.
The problem was that fill_defined_view_parts() did not return
an error if a table is going to be altered. That happened if
the table was already in the table cache. In that case,
open_table() returned non-NULL value (valid TABLE-instance from
the cache).
The fix is to ensure that an error is thrown even if the table
is in the cache.
The test case for the bug#31048 checks that there is no crash on stack
overrun. But due to different stack sizes on different platforms it failed
on some of them.
The new test case check that a query with at least 4 level subquery nesting
works without the stack overrun nesting and other levels of nesting doesn't
cause a crash.
floating point numbers
Some math functions did not check if the result is a valid number
(i.e. neither of +-inf or nan).
Fixed by validating the result where necessary and returning NULL in
case of invalid result.
Fixes the following bugs:
- Bug #33349: possible race condition revolving around data dictionary and repartitioning
Introduce retry/sleep logic as a workaround for a transient bug
where ::open fails for partitioned tables randomly if we are using
one file per table.
- Bug #34053: normal users can enable innodb_monitor logging
In CREATE TABLE and DROP TABLE check whether the table in question is one
of the magic innodb_monitor tables and whether the user has enough rights
to mess with it before doing anything else.
- Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw
- Bug #29560: InnoDB >= 5.0.30 hangs on adaptive hash rw-lock 'waiting for an X-lock'
This is a combination of changes that forward port the scalability fix applied to 5.0
through r1001.
It reverts changes r149 and r122 (these were 5.1 specific changes made in lieu of
scalability fix of 5.0)
Then it applies r1001 to 5.0 which is the original scalability fix.
Finally it applies r2082 which fixes an issue with the original fix.
- Bug #30930: Add auxiliary function to retrieve THD::thread_id
Add thd_get_thread_id() function. Also make check_global_access() function
visible to InnoDB under INNODB_COMPATIBILITY_HOOKS #define.
and ps-protocol
Finding a routine should be a transparent operation as
far as the binary log is concerned.
But it was influencing the binary log because of the TIMESTAMP
column in the proc table.
Fixed by preserving and restoring the time_zone usage flag when
searching for a stored routine in the proc table.
breaks replication
NAME_CONST() didn't replicate constant character set and collation
correctly.
With this fix NAME_CONST() inherits collation from the value argument.
a SELECT doesn't cause ROLLBACK of statem".
The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.
Problem is not about intervals and doesn't actually cause 'full table scan'.
We have an optimization for DISTINCT when we have
'DISTINCT field_from_first_join_table' we don't need to read all the
rows from the JOIN-ed table if we found one conforming row.
It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon
that case in the evaluate_join_record() and that doesn't break the
recordreading loop in sub_select().
Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.
when executed in version 5
Zero fill is a field attribute only. So we can't always
propagate constants for zerofill fields : the values and
expression results don't have that flag.
Fixed by converting the const value to a string and
using that in const propagation when the context allows it.
Disable const propagation for fields with ZEROFILL flag in
all the other cases.
two timestamp fields.
The actual problem here was that CREATE TABLE allowed zero
date as a default value for a TIMESTAMP column in NO_ZERO_DATE mode.
The thing is that for TIMESTAMP date type specific rule is applied:
column_name TIMESTAMP == column_name TIMESTAMP DEFAULT 0
whever for any other date data type
column_name TYPE == column_name TYPE DEFAULT NULL
The fix is to raise an error when we're in NO_ZERO_DATE mode and
there is TIMESTAMP column w/o default value.
from storage engine
Federated may crash a server, return wrong result set, return
"ERROR 1030 (HY000): Got error 1430 from storage engine" message
when local (engine=federated) table has a key against nullable
column.
The problem was wrong implementation of function that creates
WHERE clause for remote query from key.
