the wrong buffer
handler::index_next_same() did not take into account that the
internally called function key_cmp_if_same() uses the fixed
buffer table->record[0] for key comparison instead of the
buffer provided by the caller of handler::index_next_same().
Added code to temporarily redirect table->record[0] and the fields
used for the key to the record buffer provided by the caller of
handler::index_next_same().
The test case is in partition.test already.
The following bugs are fixed:
Bug #31860: Server crashes after inserting into InnoDB table with auto_increment column
In the Bug 16979 fix there was an erroneous assertion that
autoincrement columns can't contain negative values. With the fix, the
autoincrement table counter is set to 0 if the maximum value read from
the autoinc column index is negative.
Fixes the following bugs:
Bug #30706: SQL thread on slave is allowed to block client queries when slave load is high
Add (innodb|innobase|srv)_replication_delay MySQL config parameter.
Bug #30888: Innodb table + stored procedure + row deletion = server crash
While adding code for the low level read of the AUTOINC value from the index,
the case for MEDIUM ints which are 3 bytes was missed triggering an
assertion.
Bug #30907: Regression: "--innodb_autoinc_lock_mode=0" (off) not same as older releases
We don't rely on *first_value to be 0 when checking whether
get_auto_increment() has been invoked for the first time in a multi-row
INSERT. We instead use trx_t::n_autoinc_rows. Initialize trx::n_autoinc_rows
inside ha_innobase::start_stmt() too.
Bug #31444: "InnoDB: Error: MySQL is freeing a thd" in innodb_mysql.test
ha_innobase::external_lock(): Update prebuilt->mysql_has_locked and
trx->n_mysql_tables_in_use only after row_lock_table_for_mysql() returns
DB_SUCCESS. A timeout on LOCK TABLES would lead to an inconsistent state,
which would cause trx_free() to print a warning.
Bug #31494: innodb + 5.1 + read committed crash, assertion
Set an error code when a deadlock occurs in semi-consistent read.
In BUG#30244 added FOUND_ROWS() as an unsafe function, but that
works only in mixed mode under 5.1. There is a workaround that
can be used in statement-based mode either under 5.0 or 5.1
where the result of FOUND_ROWS() is stored into a user vari-
able and used that way instead. This will replicate correctly
even under statement-based replication, since it will write
a User_var entry to the binary log. For some other cases, the
value has to be passed explicitly.
This patch adds tests to demonstrate that the workarounds docu-
mented for statement-based replication works as advertised, and
does more extensive tests for cases that does not work under sta-
tement-based replication actually work under mixed mode by switch-
ing to row-based replication.
RENAME TABLE against a table with DATA/INDEX DIRECTORY overwrites
the file to which the symlink points.
This is security issue, because it is possible to create a table with
some name in some non-system database and set DATA/INDEX DIRECTORY
to mysql system database. Renaming this table to one of mysql system
tables (e.g. user, host) would overwrite the system table.
Return an error when the file to which the symlink points exist.
Disabling and enabling indexes on a non-empty table grows the
index file.
Disabling indexes just sets a flag per non-unique index and does not
free the index blocks of the affected indexes. Re-enabling indexes
creates new indexes with new blocks. The old blocks remain unused
in the index file.
Fixed by dropping and re-creating all indexes if non-empty disabled
indexes exist when enabling indexes. Dropping all indexes resets
the internal end-of-file marker to the end of the index file header.
It also clears the root block pointers of every index and clears the
deleted blocks chains. This way all blocks are declared as free.
commit is specific for 5.0 to eliminated non-deterministic tests.
Those tests run only in 5.1 env where there is a necessary devices such
as processlist table of info_schema.
partitioned table
Trying INSERT DELAYED on a partitioned table, that has not been
used right before, crashes the server. When a table is used for
select or update, it is kept open for some time. This period I
mean with "right before".
Information about partitioning of a table is stored in form of
a string in the .frm file. Parsing of this string requires a
correctly set up lexical analyzer (lex). The partitioning code
uses a new temporary instance of a lex. But it does still refer
to the previously active lex. The delayd insert thread does not
initialize its lex though...
Added initialization for thd->lex before open table in the delayed
thread and at all other places where it is necessary to call
lex_start() if all tables would be partitioned and need to parse
the .frm file.
Since bug@20166, which replaced the binlog file name generating to base
on pidfile_name instead of the previous glob_hostname, the binlog file
name suddenly started to be stored solely in the absolute path format,
including a case when --log-bin option meant a relative path.
What's more serious, the path for binlog file can lead unrequestedly
to pid-file directory so that after any proper fix for this bug
there might be similar to the bug report consequences for one who
upgrades from post-fix-bug@20166-pre-fix-bug@28597 to post-fix-bug@28597.
Fixed with preserving`pidfile_name' (intr.by bug@20166) but stripping
off its directory part. This restores the original logics of storing
the names in compatible with --log-bin option format and with the
requirement for --log-bin ralative path to corresond to the data directory.
Side effects for this fix:
effective fixing bug@27070, refining its test;
ensuring no overrun for buff can happen anymore (Bug#31836
insufficient space reserved for the suffix of relay log file name);
bug#31837 --remove_file $MYSQLTEST_VARDIR/tmp/bug14157.sql missed
in rpl_temporary.test;
fixes Bug@28603 Invalid log-bin default location;
