fix for BUG#1113 "INSERT into non-trans table SELECT ; ROLLBACK" does not send warning"
and
fix for BUG#873 "In transaction, INSERT to non-trans table is written too early to binlog".
Now we don't always write the non-trans update immediately to the binlog;
if there is something in the binlog cache we write it to the binlog cache
(because the non-trans update could depend on a trans table which was modified
earlier in the transaction); then in case of ROLLBACK, we write the binlog
cache to the binlog, wrapped with BEGIN/ROLLBACK.
This guarantees that the slave does the same updates.
For ROLLBACK TO SAVEPOINT: when we execute a SAVEPOINT command we write it
to the binlog cache. At ROLLBACK TO SAVEPOINT, if some non-trans table was updated,
we write ROLLBACK TO SAVEPOINT to the binlog cache; when the transaction
terminates (COMMIT/ROLLBACK), the binlog cache will be flushed to the binlog
(because of the non-trans update) so we'll have SAVEPOINT and ROLLBACK TO
SAVEPOINT in the binlog.
Apart from this rare case of updates of mixed table types in transaction, the
usual way is still clear the binlog cache at ROLLBACK, or chop it at
ROLLBACK TO SAVEPOINT (meaning the SAVEPOINT command is also chopped, which
is fine).
Note that BUG#873 encompasses subbugs 1) and 2) of BUG#333 "3 binlogging bugs when doing INSERT with mixed InnoDB/MyISAM".
Let's say the lack of comments did not help me ;)
Copying it back again and adding comments; now 3.23->4.0
replication of LOAD DATA INFILE works again.
"LOAD DATA INFILE is badly filtered by binlog-*-db rules".
There will probably be a second final one to merge Dmitri's changes
to rpl_log.result and mine.
2 new tests:
rpl_loaddata_rule_m : test of logging of LOAD DATA INFILE when the master has binlog-*-db rules,
rpl_loaddata_rule_s : test of logging of LOAD DATA INFILE when the slave has binlog-*-db rules and --log-slave-updates.
Fix for a bug with LEAST() in WHERE clause
ha_innodb.cc:
Fix for a configure bug
multi_update.result, multi_update.test:
Fix for the update with NULL's in the result set
sql_update.cc:
Fix for the update with NULL's in the result set
Fix for the update with NULL's in the result set
Fix for the update with NULL's in the result set
log-slave-updates since this causes unexpected values in
Exec_master_log_pos in A->B->C replication setup, synchronization
problems in master_pos_wait()...
Still this brokes some functionality in sql/repl_failsafe.cc
(but this file is not used now)
the first 4 bytes of the relay log. Indeed comments in mysys/mf_iocache.c
say we must always use my_b_append for such a cache.
This *could* avoid a very rare assertion failure which is:
030524 19:32:38 Slave SQL thread initialized, starting replication in log 'FIRST' at position 0, relay log '/
users/gbichot/4.1.1/mysql-test/var/log/slave-relay-bin.000001' position: 4
030524 19:32:38 next log '/users/gbichot/4.1.1/mysql-test/var/log/slave-relay-bin.000002' is currently active
mysqld: mf_iocache.c:701: _my_b_seq_read: Assertion `pos_in_file == info->end_of_file' failed.
and which seemed to happen always when the SQL thread and/or the I/O thread
were at position 4 in a relay log.
- Bug #985: "Between RESET SLAVE and START SLAVE, SHOW SLAVE STATUS is wrong."
Now RESET SLAVE puts correct info in mi->host etc. A new test rpl_reset_slave
for that.
- Bug #986: "CHANGE MASTER & START SLAVE do not reset error columns in SHOW
SLAVE STATUS". Now these reset the errors.
replicate-*-table rules which exclude 'mysql' tables
(e.g. replicate-wild-ignore-table=mysql.%).
This was already the behaviour for GRANT/REVOKE, I'm extending it to
SET PASSWORD because it seems very logical (the contrary seems illogical).
2 new tests:
- one to test if GRANT and SET PASSWORD are replicated
- one to test if they are not replicated if replicate-wild-ignore-table=mysql.%
The 2nd is also a testcase for BUG#980.
the bug with 3.23.
ChangeSet@1.1416.113.1, 2003-03-22 15:22:59+01:00, guilhem@mysql.com
Fix for #178 Replicating INSERT VALUES(USER()) crashes (SEGV) the slave
Now it does not SEGV, but USER() is still badly replicated
(it is replicated to ""), which is a lower priority bug.
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.
Revert the previous patch: MySQL would not allow creation of VARCHAR columns whose total max length is > 8000 bytes, though InnoDB can easily store them as trailing spaces are removed
Fix wrong error message: If one tried to create table with a very big row len, MySQL claimed the max len is 64 kB for InnoDB, while it normally is 8000 bytes
Monty revoked any locks for temporary tables in
ha_myisam::external_lock()
But further code bans using write cache on nonlocked tables
this makes operations much slower
BUG#797 "If query ignored on slave (replicate-ignore-table) the slave still checks if
the returned error (0) is the same as the one on the master, whereas it shouldn't
test this.
Plus a new test for BUG#797.
Fix bug: if a DELETE failed in a FOREIGN KEY error and it had already deleted some rows, then MySQL did not roll back the failed SQL statement, and also wrote it to the binlog
Added MAX_PASSWORD_LENGTH. This increased master-slave passwords to 32 bytes (Bug #766)
Fixed server crash on purge master logs or show master logs when binlog is off. (Bug #733)
Since the mysql interactive client or some other phase in communication cuts > 64 kB strings to very short, restrict the output of SHOW INNODB STATUS to at most 60 kB
Remove potential starvation of a full log buffer flush: only flush up to the lsn which was the largest at the time when we requested the full log buffer flush
os0sync.h, os0sync.c:
Fix a bug in os_event on Unix: even though we signaled the event, some threads could continue waiting if the event became nonsignaled quickly again; this made group commit less efficient than it should be
Current table is placed into read_tables set of the current join_tab->select
so get_mm_parts function thinks that current table's record is read and
tries to calculate WHERE condition with the fields of the record.
Result of these calculations is unpredictable.
Looks funny - outcome of the SELECT depends on the queries executed before.
Anyway i think we should have testcase on this part of the code.
so I commit again in a fresh tree.
Fix for bug#763 (Relay_log_space too big by 4 bytes),
plus comments and DBUG_PRINT, and we don't start replication
if --bootstrap.
Query should actually return empty result set, but currently can't, as
it attempts to store NULL in NOT NULL field, because that is a match
made by self join conditions.
In ORDER BY MySQL seems to set the key read flag also in the case where the primary key contains only a prefix of a column - not the whole column; to prevent potential bugs retrieve the whole column if the index contains a prefix of it
repository (incredible that I forgot to push, but why not).
So unfortunately the bugfix missed 3.23.57 and will be in .58 :(
Instead of looking like working (bug #198), replication between
a 3.23 slave and 4.0 master should frankly stop. Here we detect
4.0 masters in the 3.23 slave code when we see a strange Rotate
event, and in that case we print an error and stop.
4.0.13 and older masters will be "often" caught (see the patch); 4.0.14
and newer masters will always be immediately caught.
This crash happens in rather exotic case when we try to run
SELECT DISTINCT some_func(SUM(some_field)) GROUP BY another_field;
on a table with single row.
Optimizer marks this table as const, sets group=NULL (with remove_const)
thus, create_tmp_table makes mistake collecting columns for temporary table
and then crashes because the field_count gets less than hidden_columns_count.
So now for the CREATE TABLE foo (id integer NOT NULL default 9)
INSERT INTO foo VALUES (NULL); we get an error
INSERT INTO foo VALUES (1), (NULL), (2); we get one warning
and second record is set to 9
Is that what we want?
as the already-stored timestamp. Now 'created' is used only to know if
this is a first binlog or not. And we may re-use the superfluous bytes
in 5.0 when we need room.
Cleanup
ha_innodb.cc, data0type.h:
Make sure non-latin1 users can downgrade from 4.0.14 to an earlier version if they have not created DATA_BLOB column prefix indexes
thd->enter_cond() and exit_cond(), so that the I/O thread accepts to stop
when it's waiting for relay log space.
Reset ignore_log_space_limit to 0 when the SQL thread terminates.
Merge InnoDB-4.0.14: SAVEPOINT now implemented; InnoDB now accepts also column prefix keys; crashing bug in ON UPDATE CASCADE fixed; page checksum formula fixed
Could not add a testcase for this: if the test goes into a MASTER_POS_WAIT, it waits
until this terminates (even doing "connection other_con" to launch "stop slave" is blocked).
- In MASTER_POS_WAIT() don't test if the I/O slave is running, but if the SQL thread
is running.
- Some DBUG info for this bugfix.
Item_extract needs special implementation for eq().
Item_func::eq doesn't work correctly because we have to compare
Item_extract::int_type parameters also
We need to propagate this to 4.1
support issue with an unclear message which can have N reasons for appearing.
This should help us know at which point it failed, and get the errno when
my_open was involved (as the reason for the unclear message is often a
permission problem).
RESET SLAVE resets last_error and last_errno in SHOW SLAVE STATUS (without this,
rpl_loaddata.test, which is expected to generate an error in last_error, influenced
rpl_log_pos.test).
A small test update.
Added STOP SLAVE to mysql-test-run to get rid of several stupid error messages
which are printed while the master restarts and the slave attempts/manages to
connect to it and sends it nonsense binlog requests.
we now make a distinction between if the master is < 3.23.57, 3.23 && >=57, and 4.x
(before the 2 3.23 were one). This is because in 3.23.57 we have a way to distinguish between
a Start_log_event written at server startup and one written at FLUSH LOGS, so we
have a way to know if the slave must drop old temp tables or not.
Change: mi->old_format was bool, now it's enum (to handle 3 cases). However, functions
which had 'bool old_format' as an argument have their prototypes unchanged, because
the old old_format == 0 now corresponds to the enum value BINLOG_FORMAT_CURRENT which
is equal to 0, so boolean tests are left untouched. The only case were we use mi->old_format
as an enum instead of casting it implicitly to a bool, is in Start_log_event::exec_event,
where we want to distinguish between the 3 possible enum values.
Fix for bug 254 : the first Start_log_event after server startup will
have created=now(), whereas the next ones (FLUSH LOGS, auto rotation)
will have created=0. Before this, it was always now().
This way, slaves >=4.0.14 will know when they must
drop stale temp tables or not. The next task is now modify 4.0.14 to
implement this.
Add syntax SAVEPOINT id and ROLLBACK TO SAVEPOINT id. This is compatible with DB2 and Oracle but not with SQL Server. Savepoints do not do anything yet, this is just parsing.
If the autocommit is on, let handler.cc commit or rollback the whole transaction at an updating SQL statement end. This probably fixes bug number 578. The problem was that when explicit LOCK TABLES is used, then the lock count method in autocommit does not work.
Plus a changeset which I had committed but forgot to push (and this changeset is lost on
another computer, so I recreate it here). This changeset is "user-friendly SHOW BINLOG EVENTS
and CHANGE MASTER TO when log positions < 4 are used.
Bug 571: play LOAD DATA INFILE the same way on the slave as it was on the master:
if it was with IGNORE, do it with IGNORE,
if it was with REPLACE, do it with REPLACE,
and (the change) if it was with nothing, do it with nothing (not with IGNORE !!).
Bug 573: print a proper error message in case of duplicate entry in LOAD DATA INFILE
on the slave, i.e. a message where the keyname and key value appear :
'Duplicate entry '1' for key 1' and not 'Duplicate entry '%-.64s' for key %d'
