Bug #20724 FEDERATED does not honour SET INSERT_ID

• Submitted: 27 Jun 2006 16:00
• Modified: 2 Jan 2007 16:52
• Reporter: Guilhem Bichot
• Status: Verified
• Category: Server: Federated
• Severity: S3 (Non-critical)
• Version: 5.1-bk
• OS: Linux (linux)
• Triage: Triaged: D2 (Serious)

[27 Jun 2006 16: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 6: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.