Sometimes the number of really updated rows (with changed
column values) cannot be determined at the server level
alone (e.g. if the storage engine does not return enough
column values to verify that). So the only dependable way
in such cases is to let the storage engine return that
information if possible.
Fixed the bug at server level by providing a way for the
storage engine to return information about wether it
actually updated the row or the old and the new column
values are the same. It can do that by returning
HA_ERR_RECORD_IS_THE_SAME in ha_update_row().
Note that each storage engine may choose not to try to
return this status code, so this behaviour remains
storage engine specific.
SHOW CREATE TABLE or SELECT FROM I_S.
Actually, the bug discovers two problems:
- the original query is not preserved properly. This is the problem
of BUG#16291;
- the resultset of SHOW CREATE TABLE statement is binary.
This patch fixes the second problem for the 5.0.
Both problems will be fixed in 5.1.
"REPLACE/INSERT IGNORE/UPDATE IGNORE doesn't work"
Federated does not record neccessary HA_EXTRA flags in order to
support REPLACE/INSERT IGNORE/UPDATE IGNORE.
Implement ::extra() to capture flags neccessary for functionality.
New function append_ident() to better escape identifiers consistantly.
Thanks to Martin Friebe for finding and submitting a fix for this bug!
A table with maximum number of key segments and maximum length key name
would have a corrupted .frm file, due to an incorrect calculation of the
complete key length. Now the key length is computed correctly (I hope) :-)
MyISAM would reject a table with the maximum number of keys and the maximum
number of key segments in all keys. It would allow one less than this total
maximum. Now MyISAM accepts a table defined with the maximum. (This is a
very minor issue.)
CHECK TABLE against ARCHIVE table may falsely report table corruption,
or cause server crash.
Fixed by using proper buffer for CHECK TABLE.
Affects both 5.0 and 5.1.
into mysql.com:/home/ram/work/b29079/b29079.5.0
---
Bug #22540: Incorrect value in column End_log_pos of SHOW BINLOG EVENTS using InnoDB
fix binlog-writing so that end_log_pos is given correctly even
within transactions for both SHOW BINLOG and SHOW MASTER STATUS,
that is as absolute values (from log start) rather than relative
values (from transaction's start).
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
---
Bug#22540: Incorrect value in column End_log_pos of SHOW BINLOG EVENTS using InnoDB
end_log_pos data within a transaction are relative to
the start of the transaction rather than absolute.
we fix those groups in situ before writing the log out.
additional comments and handling for groups with very
large single events, as suggested by Guilhem.
---
Merge bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into amd64.(none):/src/bug24732/my50-bug24732
---
Merge maint1.mysql.com:/data/localhome/tsmith/bk/50
into maint1.mysql.com:/data/localhome/tsmith/bk/maint/50
---
Bug#22540: Incorrect value in column End_log_pos of SHOW BINLOG EVENTS using InnoDB
end_log_pos data within a transaction are relative to
the start of the transaction rather than absolute.
we fix those groups in situ before writing the log out.
additional comments and handling for groups with very
large single events, as suggested by Guilhem.
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.1-maint
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
---
Merge sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
Sometimes special 0 ENUM values was ALTERed to normal
empty string ENUM values.
Special 0 ENUM value has the same string representation
as normal ENUM value defined as '' (empty string).
The do_field_string function was used to convert
ENUM data at an ALTER TABLE request, but this
function doesn't care about numerical "indices" of
ENUM values, i.e. do_field_string doesn't distinguish
a special 0 value from an empty string value.
A new copy function called do_field_enum has been added to
copy special 0 ENUM values without conversion to an empty
string.
In the ha_partition::position we don't calculate the number of
the partition of the record. We use m_last_part_value instead relying on
that it is set in other place like previous calls of ::write_row().
In replication we do neither of these calls before ::position().
Delete_row_log_event::do_exec_row calls find_and_fetch_row() where
we used position() & rnd_pos() calls to find the record for the
PARTITION/INNODB table as it posesses InnoDB table flags.
Fixed by removing HA_PRIMARY_KEY_REQUIRED_FOR_POSITION flag from PARTITION
end_log_pos data within a transaction are relative to
the start of the transaction rather than absolute.
we fix those groups in situ before writing the log out.
additional comments and handling for groups with very
large single events, as suggested by Guilhem.
Assertion failure may happen with falcon + partition + select for
update. This may affect other engines as well.
Though assertion failure is fixed with this patch, falcon still
deadlocks when running falcon_bug_28026.test.
fix binlog-writing so that end_log_pos is given correctly even
within transactions for both SHOW BINLOG and SHOW MASTER STATUS,
that is as absolute values (from log start) rather than relative
values (from transaction's start).
---
Merge sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.1-maint
into sin.intern.azundris.com:/home/tnurnberg/22540/51-22540
fix binlog-writing so that end_log_pos is given correctly even
within transactions for both SHOW BINLOG and SHOW MASTER STATUS,
that is as absolute values (from log start) rather than relative
values (from transaction's start).
---
Merge tnurnberg@bk-internal.mysql.com:/home/bk/mysql-5.0-maint
into sin.intern.azundris.com:/home/tnurnberg/22540/50-22540
when index_init() or rnd_init() return an error, we still set
handler->inited to INDEX or RND in ha_index_init and ha_rnd_init.
As caller doesn't call ha_*_end() in this case, we get DBUG_ASSERT
failed.
LOCK TABLES takes a list of tables to lock. It may lock several
tables successfully and then encounter a tables that it can't lock,
e.g. because it's locked. In such case it needs to undo the locks on
the already locked tables. And it does that. But it has also notified
the relevant table storage engine handlers that they should lock.
The only reliable way to ensure that the table handlers will give up
their locks is to end the transaction. This is what UNLOCK TABLE
does : it ends the transaction if there were locked tables by LOCK
tables.
It is possible to end the transaction when the lock fails in
LOCK TABLES because LOCK TABLES ends the transaction at its start
already.
Fixed by ending (again) the transaction when LOCK TABLES fails to
lock a table.
Max compressed file size was calculated incorretly causing server
crash on INSERT.
With this patch we use proper max file size provided by zlib.
Affects 5.0 only.
