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.
Disabled events weren't removed from the memory queue after the scheduler has been
re-enabled. After recalculation of next execution time of an event, it might get disabled.
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.
sending SIGHUP.
There were two problems:
- after some recent fix, the server started to crash after
receiving SIGHUP. That happened because LEX of new THD-object
was not properly initialized.
- user-specified log options were ignored when logs were reopened.
The fix is to 1) initialize LEX and 2) take user-specified options
into account.
There is no test case in this CS, because our test suite does not
support sending SIGHUP to the server.
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.
