have in fact no effect, because in 4.0 the slave always runs with --skip-innodb.
In 4.1, mysqld accepts option --innodb which can override --skip-innodb.
So I add this option to the test.
When the updated test (using InnoDB tables) from 4.0 will be merged
into 4.1, with this good .opt file, we'll have a meaningful test in 4.1.
Until then, the test in 4.1 will pass but be useless.
And in 4.0, it will stay useless forever.
("it" = the part of the test which tests replication of foreign_key_checks)
Merge
trx0trx.c:
Print more info about a trx in SHOW INNODB status; try to find the bug reported by Plaxo
buf0buf.c:
Check that page log sequence numbers are not in the future
log0recv.c, log0log.c:
Fixed a bug: if you used big BLOBs, and your log files were relatively small, InnoDB could in a big BLOB operation temporarily write over the log produced AFTER the latest checkpoint. If InnoDB would crash at that moment, then the crash recovery would fail, because InnoDB would not be able to scan the log even up to the latest checkpoint. Starting from this version, InnoDB tries to ensure the latest checkpoint is young enough. If that is not possible, InnoDB prints a warning to the .err log
I extended the task to cleaning error messages, making them look nicer,
and making the output of SHOW SLAVE STATUS (column Last_error) be as complete
as what's printed on the .err file;
previously we would have, for a failure of a replicated LOAD DATA INFILE:
- in the .err, 2 lines:
"duplicate entry 2708 for key 1"
"failed loading SQL_LOAD-5-2-2.info"
- and in SHOW SLAVE STATUS, only:
"failed loading SQL_LOAD-5-2-2.info".
Now SHOW SLAVE STATUS will contain the concatenation of the 2 messages.
This is to avoid a test failure, which is fixed in 4.0 in
ChangeSet@1.1455.34.1, 2003-06-10 23:29:49+02:00, guilhem@mysql.com
by making RESET SLAVE reset the error.
and other replicate-*-table options in SHOW SLAVE STATUS.
Seems like it had not been done, so I push it now:
there's 4 new columns to SHOW SLAVE STATUS.
Fix bug: if there was a 'record too long' error in an insert, InnoDB forgot to free reserved file space extents; they were only freed in mysqld restart
Fix bug reported by Dyego Souza do Carmo: if a row becomes too long, > 8000 bytes, in an update, then InnoDB simply removes the clustered index record and does not report of table handler error 139
