On Fri, Aug 15, 2003 at 03:45:40PM -0700, Dathan Vance Pattishall wrote: > > Replicating queries where re-written to fix various bugs, most notably > time and auto-increment bugs.
Hm? I didn't quite pars that sentence. > Why doesn't replication also enforce rewriting INSERT INTO into > INSERT DELAYED / etc. File a bug report and maybe they'll fix it. > I've notice that the replicating thread in 3.23.5x will wait for a > table instead of going onto another log event iff that table is > being queried. Replcation is serialized. Completely serialized. > I would think adding DELAYED under the covers for replication would > be a big win for mysql, in keeping a slave consistent and up to > date. Unless the server crashes. > What would the drawback be? It's not waiting for an auto increment > value to be returned is there some other intrinsic problem? This > should be a win win for both 3.5x and 4.x I could see having a "replicate all queries as delayed" option for those who want to play with fire. But there could be problems. What if you do an insert that becomes delayed (and low priority) and then run an INSERT ... SELECT that tries to pull data from the talbe that the delayed insert wants to write to? What should happen in that case? Jeremy -- Jeremy D. Zawodny | Perl, Web, MySQL, Linux Magazine, Yahoo! <[EMAIL PROTECTED]> | http://jeremy.zawodny.com/ MySQL 4.0.13: up 17 days, processed 881,305,498 queries (585/sec. avg) -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
