It appears to be a consequence of having uncommitted / rollback'd InnoDB transactions.
they don't show up in `show full processlist` so it's a hard thing to debug, especially if you don't have SUPER privileges. if I did, this: show innodb status; would probably show the outstanding ones. as it is, I don't have SUPER, so a complete drop/recreation of the table was necessary. luckily was not a sqlalchemy issue. On Sunday, February 16, 2014 9:40:17 PM UTC-5, Michael Bayer wrote: > > > On Feb 16, 2014, at 8:37 PM, Mike Lessings > <[email protected]<javascript:>> > wrote: > > You are right, MySQL itself is doing something odd. However I feel like > SQLAlchemy must have done some funny locking that is causing the database > to act strangely, and I'd like to find out how and how to avoid that. > > > SQLAlchemy doesn’t “lock” anything. There’s no DBAPI lock() command. It > only emits SQL, that’s it. If you look at echo=True, that’s what it’s > doing. > > So I suggest you make a test script that connects with MySQLdb directly, > and run each command individually using cursor.execute(). This can help > to isolate at the statement level where things are going wrong. > > Or, distill your test into a single test.py with minimal tables/data/rows > which reproduces the issue (and send), it will be easy enough to figure out > where it’s hanging if that’s available. > > Both of these steps might be a little tedious but ultimately will be way > faster than trying to poke and guess, it’s how I work these things out. > > > > Any ideas what could be happening? > > > I avoid both MySQL and SELECT..FOR UPDATE so not really, sorry…. > > > > > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
