Comment 5 for bug 1074255

I had tried to reproduce this bug. I used a modified sysbench to create some compressed table and then drop them. I found another long semaphore waiting:

--Thread 139878966376192 has waited at buf0flu.c line 1454 for 303.00 seconds the semaphore:
S-lock on RW-latch at 0x44d4158 '&buf_pool->page_hash_latch'
a writer (thread id 139878934730496) has reserved it in mode exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file buf0buf.c line 2482

the purge thread was waiting for the user thread that executing 'drop table' to release buf_pool->page_hash_latch

I guess if the buffer pool or compressed table is big enough, a real crash may happen(though the user thread is working normally to free compressed pages in page_hash )

But actually the server was active. While the aim of crashing server is to avoid real hang, I think a more friendly way is needed to check the real hang.

Besides , crashing the server is very rude and may probably lead to inconsistency of data. I think we can add some option to forbid this behavior (this should be very easy)