table' lockup".
Changes from the innodb-5.0-ss92 snapshot.
Do not call os_file_create_tmpfile() at runtime. Instead, create
all tempfiles at startup and guard access to them with mutexes.
Removed include/Makefile.am and the reference to it.
Deleted db/db0err.h and db directory.
Check index column sizes in a better way (bug 13315).
Fixed comments for memory allocation functions and added
some extra checks. Adapted callers.
table' lockup".
Changes from the innodb-4.1-ss11 snapshot.
Do not call os_file-create_tmpfile() at runtime. Instead, create
a tempfile at startup and guard access to it with a mutex.
Also, fix bugs:
10511: "Wrong padding of UCS2 CHAR columns in ON UPDATE CASCADE";
13778: "If FOREIGN_KEY_CHECKS=0, one can create inconsistent FOREIGN
KEYs". When FOREIGN_KEY_CHECKS=0 we still need to check that
datatypes between foreign key references are compatible.
Also, added test cases (also for bug 9802).
Fix for bug#12429: Replication tests fail: "Slave_IO_Running" differs:
The value is not important, and it depends on timing. Mask it.
Backport and extension of a fix made by Matthias in 5.0, originally it was
1.1976 05/12/05 17:57:48 mleich@mysql.com
Now when we create or drop trigger we check that both trigger name and trigger
table always have database part specified. Thus we give an error if it they
are not specified explicitly or implicitly via current database.
in NDB that the fix would cause due to improper registration of a transaction
that isn't meant to be seen by the handler layer. (Bug #14212)
Thanks to Sergei Golubchik for helping with this.
cmp_item_sort_string::cmp() wasn't checking values_res variable for null.
Later called function was dereferenced it and crashed server.
Added null check to cmp_item_sort_string::cmp().
to Crash": the bug was that due to non-standard name
resolution precedence in stored procedures (See Bug#5967)
a stored procedure variable took precedence over a table column
when the arguments for VALUES() function were resolved.
The implementation of VALUES() function was not designed to work
with Item_splocal and crashed.
VALUES() function is non-standard. It can refer to, and
is meaningful for, table columns only. The patch disables SP
variables as possible arguments of VALUES() function.
Problem #1: INSERT...SELECT, Version for 4.1.
INSERT ... SELECT with the same table on both sides (hidden
below a MERGE table) does now work by buffering the select result.
The duplicate detection works now after open_and_lock_tables()
on the locks.
I did not find a test case that failed without the change in
sql_update.cc. I made the change anyway as it should in theory
fix a possible MERGE table problem with multi-table update.
