The incoming bug rate over the past 7 days is much lower than the past 14 days. Maybe this is a blip. But commits to trunk have begun to use 8-digit bug numbers that do not reference entries in bugs.mysql.com. I think something has changed but nothing has been announced. I like bugs.mysql.com. We all benefit by sharing bug reports and I contributed a lot of content. It is also easy to search (use "site:bugs.mysql.com" on google searches).
Assuming there was a change maybe it doesn't matter to most community members.
-
Did Windows NT not have condition variables? This might be an artifact of that. It shows what happens when you don't have a condition variable.
stop_ibuf_merges:
mutex_enter(&fil_system->mutex);
space = fil_space_get_by_id(id);
if (space != NULL) {
space->stop_ibuf_merges = TRUE;
if (space->n_pending_ibuf_merges == 0) {
mutex_exit(&fil_system->mutex);
count = 0;
goto try_again;
} else {
if (count > 5000) {
ut_print_timestamp(stderr);
fputs(" InnoDB: trying to delete tablespace ", stderr);
ut_print_filename(stderr, space->name);
}
mutex_exit(&fil_system->mutex);
os_thread_sleep(20000);
count++;
goto stop_ibuf_merges;
}
2View comments
-
If you are willing to look there are a few good changes in trunk for InnoDB. A frequent source of mutex contention in InnoDB, kernel_mutex, has been replaced with a rw-lock for the transaction system (see trx_sys_struct), two mutexes in srv_sys_struct and possibly other mutexes and rw-locks. The dulint struct has been replaced with a native 8-byte int. All of these changes should make InnoDB more efficient for workloads with a large number of concurrent transactions and help with bug 49169.
I wish there were a better to track changes in InnoDB. Right now my tools are luck and recursive diff.10View comments
View comments