When creating a temporary table that uses the same name as the mysql
privs table the server would crash on FLUSH PRIVILEGES.
This patches corrects the problem by setting a flag to ignore any
temporary table when trying to reload the privileges.
localhost/default port
When creating federated table that points to unspecified host or
localhost on unspecified port or port is 0, small memory leak occurs.
This happens because we make a copy of unix socket path, which is
never freed.
With this fix we do not make a copy of unix socket path, instead
share->socket points to MYSQL_UNIX_ADDR constant directly.
This fix is covered by a test case for BUG34788.
Affects 5.0 only.
for YEAR data type.
The problem was that for some unknown reason 0 was not allowed
as a default value for YEAR data type. That was coded before BK.
However the Manual does not say a word about such a limitation.
Also, it looks inconsistent with other data types.
The fix is to allow 0 as a default value.
Fixed the parser to reject SQLSTATE '00000',
since '00000' is the successful completion condition,
and can not be caught by an exception handler in SQL.
The bool data type was redefined to BOOL (4 bytes on windows).
Removed the #define and fixed some of the warnings that were uncovered
by this.
Note that the fix also disables 2 warnings :
4800 : 'type' : forcing value to bool 'true' or 'false' (performance warning)
4805: 'operation' : unsafe mix of type 'type' and type 'type' in operation
These warnings will be handled in a separate bug, as they are performance related or bogus.
Fixed to int the return type of functions that return more than
2 distinct values.
correctly - crashes server !
Creating federated table with connect string containing empty
(zero-length) host name and port is evaluated as 0 (port is
incorrect, omitted or 0) crashes server.
This happens because federated calls strcmp() with NULL pointer.
Fixed by avoiding strcmp() call if hostname is set to NULL.
When CREATE SERVER is issued, it allocates memory on memory root
to store cached server structure. When DROP SERVER is issued,
it doesn't release this memory, as it is impossible with the
memory root.
We use the same allocation strategy for plugins and acl. The problem
here that there was no way (except for the server restart) to force
'servers' code to release this memory.
With this fix it is possible to release unused server cache memory
by FLUSH PRIVILEGES.
No test case for this fix.
well enough
CREATE SERVER may cause server crash if there is not enough memory
to execute this operation.
Fixed that create_server() and prepare_server_struct_for_insert()
didn't check return value of functions that allocate memory.
As this is out of memory issue fix, not test case available.
binlogging of insert into a autoincrement blackhole table ignored
an explicit set insert_id.
Fixed with refining of the blackhole's insert method to call
update_auto_increment() that prepares binlogging the insert query
with the preceeding set insert_id.
Note, as the engine does not store any actual data one has to explicitly
provide to the server with the value of the autoincrement column via
set insert_id. Otherwise binlogging will happend with the default
set insert_id=1.
When swapping out heap I_S tables to disk, this is done after plan refinement.
Thus, READ_RECORD::file will still point to the (deleted) heap handler at start
of execution. This causes segmentation fault if join buffering is used and the
query is a star query where the result is found to be empty before accessing
some table. In this case that table has not been initialized (i.e. had its
READ_RECORD re-initialized) before the cleanup routine tries to close the handler.
Fixed by updating READ_RECORD::file when changing handler.
binlog_format=mixed
Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT,
INSERT ... SELECT ... LIMIT is not safe as order of rows is not
defined.
With this fix, we issue a warning that this statement is not safe to
replicate in statement mode, or go to row-based mode in mixed mode.
Note that we may consider a statement as safe if ORDER BY primary_key
is present. However it may confuse users to see very similiar statements
replicated differently.
Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but
this patch doesn't address this issue. See comment from Kristian
posted 18 Mar 10:55.
Each time the server reloads privileges containing table grants, the
system will allocate too much memory than needed because of badly
chosen growth prediction in the underlying dynamic arrays.
This patch introduces a new signature to the hash container initializer
which enables a much more pessimistic approach in favour for more
efficient memory useage.
This patch was supplied by Google Inc.
Bug #18453 Warning/error message if there is a mismatch between ...
There were three problems:
1. the reported lack of warnings for the BEFORE syntax of PURGE;
2. the similar lack of warnings for the TO syntax;
3. incompatible behaviour between the two in that the latter blanked out
regardlessly of presence or lack the actual file corresponding to
an index record; the former version gave up at the first mismatch.
fixed with deploying the warning's generation and synronizing logics of
purge_logs() and purge_logs_before_date().
my_stat() is called in either of two branches of purge_logs() (responsible
for the TO syntax of PURGE) similarly to how it has behaved in the BEFORE syntax.
If there is no actual binlog file, my_stat returns NULL and my_delete is
not invoked.
A critical error is reported to the user if a file from the index
could not be retrieved info about or deleted with a system error code
different than ENOENT.
The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.
The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.
