Fix bug #12308 : do not roll back the whhole transaction in a lock wait timeout error, just roll back the latest SQL statement; note that the locks set in the latest SQL statements remain, as InnoDB does not know what locks were set in which SQL statement
Fix bug #12410 : InnoDB was too permissive with LOCK TABLE ... READ LOCAL, and alowed new inserts to the table; we now make READ LOCAL equivalent to READ for InnoDB; note that this will cause slightly more locking in mysqldump, but makes the InnoDB table dumps consistent with MyISAM table dumps; note that the real code change patch was accidentally pushed with my another patch 5 minutes ago
Fix bug #12852 : do not increment the open handle count to a table if the table does not have an .ibd file and InnoDB decides to return an error from the ::open() function; then the table can be dropped even if the user has tried to open it
Fix bug #12779 : never give a row count estimate of 0 to the MySQL query optimizer, as then left join optimizer may beleive it KNOWS that the table is empty; note that this fix may change query optimization of many other queries where one table is empty; note that the proper fix would be to make the query optimizer to know that the row count estimates it receives really are just estimates, it cannot assume they are certain
sql_print_warning() and sql_print_error() instead of fprintf to stderr.
Above functions are tuned for different platforms so that the behavior
is consistent around platforms. Using fprintf() different behavior can
be expected at least on Windows and Unix.
When PRIMARY KEY is present ha_innobase::cmp_ref() uses it to compare refs.
After comparing part of key it moves pointers to compare next part.
For varchar parts pointers were moved only by length of parts, not including
bytes containig part length itself. This results in wrong comparision and
wrong number of deleted records.
Push the patch of Jan Lindstrom: better comments
ha_innodb.cc:
Partial fix for Bug #12263 : we let InnoDB always to perform a rollback on the trx object if MySQL closes a connection; but we do print a warning to the .err log if an InnoDB transaction was active; we may remove that print later, since the situation really is not a bug; MySQL just is not aware that some cursor operation started an InnoDB transaction
cursors for InnoDB. The idea of the patch is that if MySQL requests
a consistent read view, we open one when open a cursor, set is as the
active view to a transaction when fetch from the cursor, and close
together with cursor close. This patch is associated to bugs #11813,
#11832, and #11833. Contains after review fixes.
cursors. This should fix Bug#11813 when InnoDB part is in
(tested with a draft patch).
The idea of the patch is that if a storage engine supports
consistent read views, we open one when open a cursor,
set is as the active view when fetch from the cursor, and close
together with cursor close.
The idea of the patch
is that every cursor gets its own lock id for table level locking.
Thus cursors are protected from updates performed within the same
connection. Additionally a list of transient (must be closed at
commit) cursors is maintained and all transient cursors are closed
when necessary. Lastly, this patch adds support for deadlock
timeouts to TLL locking when using cursors.
+ post-review fixes.
Changed defaults option --instance to --defaults-group-suffix
Changed option handling to allow --defaults-file, --defaults-extra-file and --defaults-group-suffix to be given in any order
Changed MYSQL_INSTANCE to MYSQL_GROUP_SUFFIX
mysql_print_defaults now understands --defaults-group-suffix
Remove usage of my_tempnam() (not safe function)
if( -> if ( and while( to while (
Let InnoDB use a consistent read when it initializes the auto-inc counter for a table: this will eliminate spurious deadlocks, but will ignore an UPDATE if that happens at the same time that we init the auto-inc counter; this has to be documented; this path also fixes most of Bug #11633, but not all: if ::external_lock() is not called on the table in SHOW TABLE STATUS, that might cause a crash if someone simultaneously DROPs the table
Since UNLOCK TABLES will commit the transaction (and thus release
all InnoDB locks held by it), it is unnecessary to release the
user-requested table locks separately.
Update the InnoDB internal auto-inc counter in ::write_row() if the statement is a REPLACE that fails in a duplicate key error: REPLACE will handle duplicate key error, and the insert will eventually succeed; note that we did NOT change InnoDB's behavior in an UPDATE, because updating the auto-inc counter in an UPDATE would require a bigger patch (Bug #11005)
