The 4.0 changeset was:
ChangeSet@1.1579.3.1, 2003-09-26 23:43:22+02:00, guilhem@mysql.com
Fix for 64-bit machines.
I am almost sure this is the cause for
BUG#1381 [Opn]: Bug in replication on HP-UX 64 bit binaries?
BUG#1256 [CRp]: Replication slave fails to connect to master in 64-bit version
(Solaris)
The reason why I think it's wrong is that the normal client code has
uint32 ip_addr.
(of course on 32-bit machines it does not matter, but on 64-bit it does).
DO NOT COPY THIS CODE TO 4.0. The bugfix is better in 4.0,
but here in 3.23 we don't want to add a new error code so
we just use ER_EMPTY_QUERY. Bug was:
"If a query was ignored on the slave (because of
@code{replicate-ignore-table} and other similar rules), the slave
still checked if the query got the same error code (0, no error) as on
the master. So if the master had an error on the query (for example,
``Duplicate entry'' in a multiple-row insert), then the slave stopped
and warned that the error codes didn't match. (Bug #797)"
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.
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.
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.
Fix a bug: a race condition could cause that the first B-tree page splits would get a corrupt page directory, whic often results in the assertion in page_dir_find_slot(); found with a test of 3000 startups/shutdowns; it is not clear that this would have caused any corruption which users have reported
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.
Prevent the InnoDB main thread from hogging CPU if a table lingers in the background drop queue (though it is essentially a bug if a table end up there at all)
