Aryeh Gregor schrieb: > That doesn't normally happen with InnoDB, AFAIK. Selects don't block > updates; the selects just read the old, un-updated rows as the update > proceeds, using MVCC. Uncommitted updates don't even necessarily > block ordinary selects AFAIK -- again, the select can just get a > consistent read of the old version. See here for details (and other > pages in the section): > > http://dev.mysql.com/doc/refman/5.1/en/innodb-locks-set.html > http://dev.mysql.com/doc/refman/5.1/en/innodb-lock-modes.html > > So an ordinary select should not take out any locks, and therefore not > block any other statement at all from occurring except maybe things > like ALTER TABLE. However, selects do take out locks if used with > LOCK IN SHARE MODE or FOR UPDATE, or if they're run at SERIALIZABLE > isolation level. I would guess one of those was the culprit, without > being able to see the exact query.
Actually, I think the problem is not an UPDATE or INSERT, the problem is that I use mysqldump to make a copy and then import the resulting dump - which starts by *dropping* the table and re-creating it. Apparently, the DROP is not performed while a SELECT is in progress (makes sense). A workable solution would be to suppress the DROP (there's an option for that) and to use REPLACE instead of INSERT - but that is only supported by mysqldump since 5.1.3 apparently, we are on 5.0.something. Also, it would not propagate row deletions - not a big deal in this case though, since rows rarely get killed from toolserver.* tables. Seems like I need to write my own mysqlcopy or something... -- daniel _______________________________________________ Toolserver-l mailing list ([email protected]) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
