- Removed not used variables
- Changed some ulong parameters/variables to ulonglong (possible serious bug)
- Added casts to get rid of safe assignment from longlong to long (and similar)
- Added casts to function parameters
- Fixed signed/unsigned compares
- Added some constructores to structures
- Removed some not portable constructs
Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
(Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
Fixed some possible fatal wrong arguments to printf() style functions
Initialized some not initialized variables
Fixed bug in stored procedure and continue handlers
(Fixes Bug#22150)
---
BUG#20265 (Replication of CREATE-SELECT does not work correctly):
Fixing bug by making binary log handle statement transactions.
The binary log transaction cache can now be truncated to remove
events inserted during this statement or transaction. Also, the
binary log participate in XA transaction handling, although not
as a full 2pc resource.
On an INSERT into an updatable but non-insertable view an error message was
issued stating the view being not updatable. This can lead to a confusion of a
user.
A new error message is introduced. Is is showed when a user tries to insert
into a non-insertable view.
Bug#20627 - INSERT DELAYED does not honour auto_increment_* variables
INSERT DELAYED ignored an explicitly set INSERT_ID and session
specific auto_increment_* variables.
The problem was that the inserts are done by a system thread,
which does not have access to the session variables of the user
thread.
On a proposal of Guilhem I fixed it so that the variables are
copied to the data structure for every delayed row. The system
thread sets its session variables from these values.
containing a select statement that uses an aggregating IN subquery.
Added a parameter to the function fix_prepare_information
to restore correctly the having clause for the second execution.
Saved andor structure of the having conditions at the proper moment
before any calls of split_sum_func2 that could modify the having structure
adding new Item_ref objects. (These additions, are produced not with
the statement mem_root, but rather with the execution mem_root.)
In practice this means that handlerton is now created by the server and is passed to the engine. Plugin startups can now also control how plugins are inited (and can optionally pass values). Bit more flexibility to those who want to write plugin interfaces to the database.
The cause of the bug was an incomplete fix for bug 18080.
The problem was that setup_tables() unconditionally reset the
name resolution context to its 'tables' argument, which pointed
to the first table of an SQL statement.
The bug fix limits resetting of the name resolution context in
setup_tables() only in the cases when the context was not set
by earlier parser/optimizer phases.
(as part of the auto_increment cleanup of WL#3146; let's not be
sad, that monster push still removed serious bugs):
one problem with INSERT DELAYED (unexpected interval releases),
one with stored functions (wrong auto_inc binlogging).
These bugs were not released.
This bug report was two problems:
1) LAST_INSERT_ID() returns a value which does not exist in the table
2) the reporter would want it to return the autoinc id of the updated
row.
1) is a real bug, 2) is a feature request.
In July I implemented 2) in 5.1 (which automatically fixes 1).
This has not yet been documented or released, so is changeable.
Precisely, recently Paul and a user found an easy workaround to give
2), which works in 4.1-5.0-5.1. So I can revert my code for 2),
because it's not needed, that's what I do here;
we forget about 2) (we will document the workaround).
But when I revert my code for 2), 1) comes back. We solve 1) by saying
that if INSERT ON DUPLICATE KEY UPDATE updates a row, it's like a
regular UPDATE: LAST_INSERT_ID() should not be affected (instead of
returning a non-existent value).
So note: no behaviour change compared to the last released 5.1; just
a bugfix for 1).
SELECT right instead of INSERT right was required for an insert into to a view.
This wrong behaviour appeared after the fix for bug #20989. Its intention was
to ask only SELECT right for all tables except the very first for a complex
INSERT query. But that patch has done it in a wrong way and lead to asking
a wrong access right for an insert into a view.
The setup_tables_and_check_access() function now accepts two want_access
parameters. One will be used for the first table and the second for other
tables.
Continued implementation of WL#1324 (table name to filename encoding)
The intermediate (not temporary) files of the new table
during ALTER TABLE was visible for SHOW TABLES. These
intermediate files are copies of the original table with
the changes done by ALTER TABLE. After all the data is
copied over from the original table, these files are renamed
to the original tables file names. So they are not temporary
files. They persist after ALTER TABLE, but just with another
name.
In 5.0 the intermediate files are invisible for SHOW TABLES
because all file names beginning with "#sql" were suppressed.
This failed since 5.1.6 because even temporary table names were
converted when making file names from them. The prefix became
converted to "@0023sql". Converting the prefix during SHOW TABLES
would suppress the listing of user tables that start with "#sql".
The solution of the problem is to continue the implementation of
the table name to file name conversion feature. One requirement
is to suppress the conversion for temporary table names.
This change is straightforward for real temporary tables as there
is a function that creates temporary file names.
But the generated path names are located in TMPDIR and have no
relation to the internal table name. This cannot be used for
ALTER TABLE. Its intermediate files need to be in the same
directory as the old table files. And it is necessary to be
able to deduce the same path from the same table name repeatedly.
Consequently the intermediate table files must be handled like normal
tables. Their internal names shall start with tmp_file_prefix
(#sql) and they shall not be converted like normal table names.
I added a flags parameter to all relevant functions that are
called from ALTER TABLE. It is used to suppress the conversion
for the intermediate table files.
The outcome is that the suppression of #sql in SHOW TABLES
works again. It does not suppress user tables as these are
converted to @0023sql on file level.
This patch does also fix ALTER TABLE ... RENAME, which could not
rename a table with non-ASCII characters in its name.
It does also fix the problem that a user could create a table like
`#sql-xxxx-yyyy`, where xxxx is mysqld's pid and yyyy is the thread
ID of some other thread, which prevented this thread from running
ALTER TABLE.
Some of the above problems are mentioned in Bug 1405, which can
be closed with this patch.
This patch does also contain some minor fixes for other forgotten
conversions. Still known problems are reported as bugs 21370,
21373, and 21387.
We now reset the THD members related to auto_increment+binlog in
MYSQL_LOG::write(). This is better than in THD::cleanup_after_query(),
which was not able to distinguish between SELECT myfunc1(),myfunc2()
and INSERT INTO t SELECT myfunc1(),myfunc2() from a binlogging point
of view.
Rows_log_event::exec_event() now calls lex_start() instead of
mysql_init_query() because the latter now does too much (it resets
the binlog format).
this is a cleanup patch for our current auto_increment handling:
new names for auto_increment variables in THD, new methods to manipulate them
(see sql_class.h), some move into handler::, causing less backup/restore
work when executing substatements.
This makes the logic hopefully clearer, less work is is needed in
mysql_insert().
By cleaning up, using different variables for different purposes (instead
of one for 3 things...), we fix those bugs, which someone may want to fix
in 5.0 too:
BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
statement-based"
BUG#20341 "stored function inserting into one auto_increment puts bad
data in slave"
BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
(now if a row is updated, LAST_INSERT_ID() will return its id)
and re-fixes:
BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
(already fixed differently by Ramil in 4.1)
Test of documented behaviour of mysql_insert_id() (there was no test).
The behaviour changes introduced are:
- LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
successfully inserted", instead of "the first autogenerated auto_increment
value if any row was successfully inserted", see auto_increment.test.
Same for mysql_insert_id(), see mysql_client_test.c.
- LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
mysql_client_test.c.
- LAST_INSERT_ID() does not change if no autogenerated value was successfully
inserted (it used to then be 0), see auto_increment.test.
- if in INSERT SELECT no autogenerated value was successfully inserted,
mysql_insert_id() now returns the id of the last inserted row (it already
did this for INSERT VALUES), see mysql_client_test.c.
- if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
(it already did this for INSERT VALUES), see mysql_client_test.c.
- NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
influences not only the first row now.
Additionally, when unlocking a table we check that the thread is not keeping
a next_insert_id (as the table is unlocked that id is potentially out-of-date);
forgetting about this next_insert_id is done in a new
handler::ha_release_auto_increment().
Finally we prepare for engines capable of reserving finite-length intervals
of auto_increment values: we store such intervals in THD. The next step
(to be done by the replication team in 5.1) is to read those intervals from
THD and actually store them in the statement-based binary log. NDB
will be a good engine to test that.
