Bug #20339 stored procedure using LAST_INSERT_ID() does not replicate statement-based
| Submitted: | 8 Jun 2006 12:15 | Modified: | 29 Sep 2006 2:32 |
|---|---|---|---|
| Reporter: | Guilhem Bichot | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.1-bk | OS: | Linux (linux) |
| Assigned to: | Guilhem Bichot | CPU Architecture: | Any |
[8 Jun 2006 12:15]
Guilhem Bichot
[11 Jul 2006 8:53]
Guilhem Bichot
FYI I have fixed this in 5.1.12 (but maybe you will want to fix it in 5.0): ChangeSet guilhem@gbichot3.local|ChangeSet|20060709155219|25206 2006/07/09 17:52:19+02:00 guilhem@gbichot3.local +30 -0 WL#3146 "less locking in auto_increment": this is a cleanup patch for our current auto_increment handling: new names for auto_increment variables in THD, new methods to manipulate them (see sql_class.h), some move into handler::, causing less backup/restore work when executing substatements. This makes the logic hopefully clearer, less work is is needed in mysql_insert(). By cleaning up, using different variables for different purposes (instead of one for 3 things...), we fix those bugs, which someone may want to fix in 5.0 too: BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate statement-based"
[21 Aug 2006 4:16]
Lars Thalmann
Pushed into 5.1.12. Document in manual that this is a limitation for 5.0.
[29 Sep 2006 2:32]
Paul DuBois
Noted in 5.1.12 changelog. A stored procedure that used LAST_INSERT_ID() did not replicate properly using statement-based binary logging. Also noted as a replication limitation in the 5.0 manual.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.055 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.