Bug #19887 | concurrent updates restricted by queries not using the binlog | ||
---|---|---|---|
Submitted: | 17 May 2006 15:17 | Modified: | 21 May 2006 15:19 |
Reporter: | Martin Friebe (Gold Quality Contributor) (OCA) | Email Updates: | |
Status: | Verified | Impact on me: | |
Category: | MySQL Server: Locking | Severity: | S4 (Feature request) |
Version: | 4.1 / 5.0 | OS: | Any (*) |
Assigned to: | CPU Architecture: | Any |
[17 May 2006 15:17]
Martin Friebe
[19 May 2006 10:43]
Martin Friebe
tested on 5.0.17 too
[21 May 2006 13:41]
Valeriy Kravchuk
Thank you for a problem report. If you want to check on latest versions, use 4.1.19 and 5.0.21, please. But it looks like this behaviour is intended and described at that manual pages you quoted: "If you are using the binary log, concurrent inserts are converted to normal inserts for CREATE ... SELECT or INSERT ... SELECT statements." So, it's clear: "If you are using binary log", not if your particular statement "should be written to the binary log" etc. I think this is a valid and reasonable feature request (maybe, even easy to implement one), but not a bug, formally. Do you agree?
[21 May 2006 13:53]
Martin Friebe
agreed to feature request. I believe closed bug #7879, describes the locations, where this would need to be implemented or checked. I believe 7879 was where those restrictions were implemented? on a personal note: I believe this feature could benefit many. As it would allow multi-step statistics/reports/analytics on large data, with far less impact on running applications Thanks
[4 Oct 2008 20:43]
Konstantin Osipov
As part of fix for Bug#34306, if you use row-based replication concurrent insert is employed automatically. We don't take into account replicate-do* patterns though.