>>>>> "Joe" == Joe Kislo <kislo@stripped> writes:
>> Any change that you can try and test 3.23.12 with this when it comes
>> ut (hopefully within 48 hours)? We did a small redesign of the DROP /
>> LOCK code in 3.23 and it should be much better than the old one.
>>
>> Regards,
>> Monty
Joe> Doah. That didn't take long. Here's the processlist from my linux box
Joe> running 3.22.32-log:
Joe> | 30 | TT_fcgi | localhost | TT_fcgi | Query | 211 | Waiting on
Joe> cond | DROP table
Joe> Event;
>
Joe> |
Joe> | 35 | TT_fcgi | localhost | TT_fcgi | Query | 211 | Waiting for
Joe> table | INSERT into Event (eventAction, rawTimeCreated, courseID,
Joe> sectionID, eventCode, rawTimeUpdated, even |
Joe> | 38 | TT_fcgi | localhost | TT_fcgi | Query | 211 |
Joe> Locked | LOCK TABLES Event_CLASS WRITE, Event
Joe> WRITE; |
Joe> | 39 | TT_fcgi | localhost | TT_fcgi | Query | 200 | Waiting for
Joe> table | show columns from
Joe> Event;
>
Joe> |
Joe> I'll fetch the 3.23 build and see if I can get it to do the same. LOCK
Joe> TABLES is a ALL-OR-WAIT mechinism right.. It's not like I swiped one
Joe> lock, and is waiting on the other?
No, it's not a ALL-OR-WAIT; It gets one lock at the time in a
predeterminate order (see last email) that ensures that the locking is
dead lock free. (The problem is that DROP TABLE will in this case
defeat the normal locking mechanism)
Joe> I am locking two tables at the same
Joe> time, and dropping one of them. Does it release BOTH locks or just
Joe> one? Perhaps a moot question since it seems like from the above
Joe> processlist the DROP table is -not- returning.
Regards,
Monty
