binlog coordinates corresponding to the dump".
The good news is that now mysqldump can be used to get an online backup of InnoDB *which works for
point-in-time recovery and replication slave creation*. Formerly, mysqldump --master-data --single-transaction
used to call in fact mysqldump --master-data, so the dump was not an online dump (took big lock all time of dump).
The only lock which is now taken in this patch is at the beginning of the dump: mysqldump does:
FLUSH TABLES WITH READ LOCK; START TRANSACTION WITH CONSISTENT SNAPSHOT; SHOW MASTER STATUS; UNLOCK TABLES;
so the lock time is in fact the time FLUSH TABLES WITH READ LOCK takes to return (can be 0 or very long, if
a table is undergoing a huge update).
I have done some more minor changes listed in the paragraph of mysqldump.c.
WL#2237 "WITH CONSISTENT SNAPSHOT clause for START TRANSACTION":
it's a START TRANSACTION which additionally starts a consistent read on all
capable storage engine (i.e. InnoDB). So, can serve as a replacement for
BEGIN; SELECT * FROM some_innodb_table LIMIT 1; which starts a consistent read too.
DROP DATABASE failed because of file ext not in TYPELIB of known extensions.
General solution - construct a TYPELIB at runtime instead of a static list.
the result takes its charset/collation
attributes from the character string,
e.g. SELECT func(NULL, _latin2'string')
now returns a latin2 result. This is
done by introducing a new derivation
(aka coercibility) level DERIVATION_IGNORABLE,
which is used with Item_null.
2. 'Pure' NULL is now BINARY(0), not CHAR(0).
I.e. NULL is now more typeless.
Bug #6479 ALTER TABLE ... changing charset fails for TEXT columns
Fix: use do_conv_blob rather than do_copy_blob
if the column's character sets are different.
1) fix so that missing blob tables don't prevent table from being
dropped
2) decrease size of blob part if record length exceeds max length
3) add test case for table wo/ corresponding blob table
4) init scan counters when sending scan_tabreq
Now thd->mem_root is a pointer to thd->main_mem_root and THR_MALLOC is a pointer to thd->mem_root.
This gives us the following benefits:
- Allow us to easily detect if arena has already been swapped before (this fixes a bug in setup_conds() where arena was swaped twice in some cases)
- Faster swaps of arenas (as we don't have to copy the whole MEM_ROOT)
- We don't anymore have to call my_pthread_setspecific_ptr(THR_MALLOC,...) to change where memory is alloced. Now it's enough to set thd->mem_root
Added cases for bugs #6307 and #6460.
sql_select.cc:
Fixed the problem of bug reports #6307 and #6460.
The reported wrong result sets were due to the fact that
the added call of the fix_fields method for the built
AND condition that joined WHERE and ON conditions
broke ON expression, as it removed extra AND levels
in the built condition.
It looks like that no attributes of the built condition
are needed, so we don't have to call fix_fields here.
My previous change that "set @a=NULL" doesn't change charset
fixed 'Bug #6321' as well. Prove with a new test that
FIELD(<uservariable content NULL>, ...) now works fine too.
Added a case for bug #6365.
item_cmpfunc.cc:
Fixed bug #6365 : Server crashed when list of values
in IN predicate contains NULL while the tested field is
of the character type and not of the default set;
e.g. when f in 'f IN (NULL,'aa') belongs to binary
character set, while the default character set is latin1.
the fact that the transaction log is empty does not mean we're not in a transaction
(it could be BEGIN; SELECT * FOR UPDATE FROM ibtable: then we don't want to commit now, even if
the statement is a MyISAM update).
With a testcase.
"SHOW CREATE TABLE" mysql-4.0 and mysql-3.23
compatibiliry mode change:
Check that a binary collation adds 'binary'
suffix into a char() column definition in
mysql40 and mysql2323 modes. This allows
not to lose the column's case sensitivity
when loading the dump in pre-4.1 servers.
value if server runs in time zone with leap seconds".
Now in my_gmt_sec() function we take into account difference between
our target and estimation in seconds part.
The idea of the fix is that the administrative statements
OPTIMIZE TABLE, REPAIR TABLE and ANALYZE TABLE should not
generate binlog errors if there is no errors on the master.
Added protocol::flush() for easier embedded-server code
Increase block allocation variables a bit as they where a bit too small for MySQL 4.1
Added option --silent to client_test
WL#2067 add features to mysqltest: "disable_error_abort" + "$mysql_errno"
$mysql_errno is a new builtin variable of mysqltest and contains the
return code of the last command send to the server.
"--disable_abort_on_error" switches the abort of mysqltest
after "unmasked" failing statements off.
"--enable_abort_on_error" switches the abort of mysqltest
after "unmasked" failing statements on. (default)
"Maskings" are
!$<error number> and --error <error number>
in the line before the statement to be checked.
The benefit of the option "--disable_abort_on_error" is that
- all statements after the failing statement are executed
- a r/<test>.reject will be produced
- it is possible to write test cases, which perform
code sequences depending on the return code of a single
statement
constant with a column. The string is converted into the column
character set. It conversion doesn't lose data, then operation
is possible. Otherwise, give an error, as it was earlier.
new define for long signal section size
bumbed up limit for attributes to 128
use new define in SectionSegment
some bug fixing of send fragmented signal +
make chunk size a multiple the dew define for SectionSegment size
improved mechanisn of detection posibility to be NULL for single row queries
switched off substitution optimisation for single row subqueries in PS due to problem in resolving substituted expressions
(changes to make subselects test working with PS protocol)
New mysqltest that can run mysqltest with PS
Added support for ZEROFILL in PS
Fixed crash when one called mysql_stmt_store_result() without a preceding mysql_stmt_bind_result()
Updated test cases to support --ps-protocol
(Some tests are still run using old protocol)
Fixed crash in PS when using SELECT * FROM t1 NATURAL JOIN t2...
Fixed crash in PS when using sub queries
Create table didn't signal when table was created. This could cause a "DROP TABLE created_table" in another thread to wait "forever"
Fixed wrong permissions check in PS and multi-table updates (one could get permission denied for legal quries)
Fix for PS and SELECT ... PROCEDURE
Reset all warnings when executing a new PS query
group_concat(...ORDER BY) didn't work with PS
Fixed problem with test suite when not using innodb
The same problem with SET columns:
find_set() now executes find_type2() to do charset aware search,
instead of always using system_charset_info comparison.
prepared statements when LIMIT is used" and post-review comments.
The fix changes the approach we calculate the need for ORDER BY
in UNION: the previous was not PS friendly, as it damaged SELECT_LEX
options in case of single select.
Removed the assumption of a certain key order.
Since 4.1, keys are padded with blanks for comparison.
Hence, shorter keys sort behind longer keys, if the
data bytes have values below BLANK.
he has SELECT and INSERT privileges for table with primary key"
Now we set lex->duplicates= DUP_UPDATE right in parser if INSERT has
ON DUPLICATE KEY UPDATE clause, this simplifies insert_precheck()
function (this also fixes a bug) and some other code.
Rename innodb_table_locks_old_behavior -> innodb_table_locks
Set innodb_table_locks to off by default to get same behaviour as in MySQL 4.0.20
(This means that Innodb ignore table locks by default, which makes it easier to combine MyISAM and InnoDB to simulate a transaction)
as we already have db_len in Log_event. Only if rewrite_db() changed the db we need a strlen
(so we now do the strlen() in rewrite_db). Plus a test (we had none for --replicate-rewrite-db :( ).
X-locks on duplicates also on LOAD DATA...REPLACE clause and
fixes a bug #6086 adding --disable_warnings and --enable_warnings around
the create table clauses in ctype_utf8 tests for InnoDB.
crashes server." The fix makes Item_func_rand prepared-statements
aware plus it fixes the case when RAND is used in prepared
statements and replication is on (as well as several similar issues).
Until now we did not reset THD before every execution of a prepared
statement, so if some execution had set thd->time_zone_used
or thd->rand_used they would not be reset until next mysql_parse.
Some of post-review fixes done.
- 'ps_10nestset' uses a "nested set" approach for an employee
hierarchy, then does arithmetic on the "salary" field;
(soon) to be extended by inserts / deletes which imply
mass updates on the "l"/"r" fields showing the set inclusion,
- 'ps_11bugs' will get (some of ?) those bug DB entries which
refer to prepared statements, but whose number does not appear
in a test file comment - so it will also be extended.
when one connection had done FLUSH TABLES WITH READ LOCK, some updates, and then COMMIT,
it was accepted but my_error() was called and so, while client got no error, error was logged in binlog.
We now don't call my_error() in this case; we assume the connection know what it does.
This problem was specific to 4.0.21. The change is needed to make replication work with existing versions of innobackup.
added blob to test to see that blob tables don't show up in show tables
auto increment setting need not fetch blob tables (will otherwise generate error during table creation)
moved addBlobTables out of fetchGlobalTableImpl to get_local_table_info
changed addBlobTables to start from last column and break if all blobs added
also addBlobTables will return -1 if failed (typically getTable)
changed to using get_local_table_info with internal table name where applicable for efficiency
added option to get_local_table_info wether to fetch blob tables or not
getTable always fetches the blobtables
moved addBlobTables to get_local_table_info to always be called, even if main table goes to cache only
(Bug #4315: GROUP_CONCAT with ORDER BY returns strange results for TEXT fields
Bug #5564: Strange behaviour with group_concat and distinct
Bug #5970: group_concat doesn't print warnings)
crashes server (prepared statements)": the bug was that all boolean
items always recovered its original arguments at statement cleanup
stage.
This collided with Item_subselect::select_transformer, which tries to
permanently change the item tree to use a transformed subselect instead of
original one.
So we had this call sequence for prepare:
mysql_stmt_prepare -> JOIN::prepare ->
Item_subselect::fix_fields -> the item tree gets transformed ->
Item_bool_rowready_func2::cleanup, item tree is recovered to original
state, while it shouldn't have been;
mysql_stmt_execute -> attempts to execute a broken tree -> crash.
Now instead of bluntly recovering all arguments of bool functions in
Item_bool_rowready_func2::cleanup, we recover only those
which were changed, and do it in one place.
There still would exist a possibility for a collision with subselect
tranformation, if permanent and temporary changes were performed at the
same stage.
But fortunately subselect transformation is always done first, so it
doesn't conflict with the optimization done by propogate_cond_constants.
Now we have:
mysql_stmt_prepare -> JOIN::prepare -> subselect transformation
permanently changes the tree -> cleanup doesn't recover anything,
because nothing was registered for recovery.
mysql_stmt_execute -> JOIN::prepare (the tree is already transformed,
so it doesn't change), JOIN::optimize ->
propogate_cond_constants -> temporary changes the item tree
with constants -> JOIN::execute -> cleanup ->
the changes done by propogate_cond_constants are recovered, as
they were registered for recovery.
crashes mysqld": implementation for a generic item tree modifications
registry. Every item tree modification which should be rolled back for
subsequent execution of a prepared statement or stored procedure should
be saved in the registry. All such modifications are rolled back at once
during cleanup stage of PS.
Actual fix for the bug just adds a call to register modifications to
convert_constant_item.
Post review fixes implemented.
to auto_increment in 4.1".
Now we are enforcing NO_AUTO_VALUE_ON_ZERO mode during ALTER TABLE only
if we are converting one auto_increment column to another auto_increment
column (this also includes most common case when we don't do anything
with such column).
Also now when we convert some column to TIMESTAMP NOT NULL column with
ALTER TABLE we convert NULL values to current timestamp, (as we do this
in INSERT). One can still get old behavior by setting system TIMESTAMP
variable to 0.
column types TIMESTAMP is NOT NULL by default, so in order to have
TIMESTAMP column holding NULL valaues you have to specify NULL as
one of its attributes (this needed for backward compatibility).
Main changes:
Replaced TABLE::timestamp_default_now/on_update_now members with
TABLE::timestamp_auto_set_type flag which is used everywhere
for determining if we should auto-set value of TIMESTAMP field
during this operation or not. We are also use Field_timestamp::set_time()
instead of handler::update_timestamp() in handlers.