Bug #20724 FEDERATED does not honour SET INSERT_ID
Submitted: 27 Jun 2006 14:00 Modified: 2 Jan 2007 15:52
Reporter: Guilhem Bichot Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Server: Federated storage engine Severity:S3 (Non-critical)
Version:5.1-bk OS:Linux (linux)
Assigned to: CPU Architecture:Any
Triage: Triaged: D2 (Serious)

[27 Jun 2006 14:00] Guilhem Bichot
Description:
didn't test with 5.0.
I edited federated.test like this:
===== t/federated.test 1.25 vs edited =====
*** /home/mysql_src/mysql-5.1-new-WL3146-handler/BitKeeper/tmp/bk_federated.test-1.25_Jdi8vY    2006-06-04 17:52:05 +02:00
--- edited/t/federated.test     2006-06-27 15:58:29 +02:00
***************
*** 153,158 ****
--- 153,159 ----
    ENGINE="FEDERATED" DEFAULT CHARSET=latin1
    CONNECTION='mysql://root@127.0.0.1:$SLAVE_MYPORT/federated/t1';

+ set insert_id=1234;
  INSERT INTO federated.t1 (name, other) VALUES ('First Name', 11111);
  INSERT INTO federated.t1 (name, other) VALUES ('Second Name', 22222);
  INSERT INTO federated.t1 (name, other) VALUES ('Third Name', 33333);
And the test showed no difference in result except the "set insert_id=1234" line, which means that the "SELECT * FROM federated.t1" which is a few lines below in the test, shows the same data as without the SET INSERT_ID, thus
SET INSERT_ID is not respected.
Note that this breaks recovery from statement-based binlogs, and statement-based replication.

How to repeat:
see description
[7 Aug 2007 4:59] Uri H
It also happens to me using MySQL Community v5.0.41 and v5.0.45 under Windows XP/2003.

The main issue I have with it is that it makes replication inconsistent.