> The "OS thread id" section of TRANSACTION output from "SHOW ENGINE
> INNODB STATUS" appears to have been removed. There was no changelog
> entry for this that I could find, and Launchpad only has this
> unhelpful "merge from trunk" commit message with a huge pile of other
> unrelated changes:
> First off, where can I find a real commit message?
bzr branch lp:mysql-server
bzr log -p --show-ids -rrevid:marko.makela@stripped
committer: Marko Mäkelä <marko.makela@stripped>
branch nick: 5.5-innodb
timestamp: Tue 2011-04-05 10:18:43 +0300
Bug 12323643 - CLEAN UP THE INNODB THREAD SHUTDOWN AND ASSERTIONS (WL#5136)
Remove most references to thread id in InnoDB. Three references
remain: the current holder of a mutex, and the current x-lock holder
of a rw-lock, and some references in UNIV_SYNC_DEBUG checks. This
allows MySQL to change the thread associated to a client connection.
Tighten the UNIV_SYNC_DEBUG checks, trying to ensure that no InnoDB
mutex or x-lock is being held when returning control to MySQL. The
only semaphore that may be held is the btr_search_latch in shared mode.
sync_thread_levels_empty_except_dict(): A wrapper for
sync_thread_levels_nonempty_trx(): Check that the current thread is
not holding any InnoDB semaphores, except btr_search_latch if
sync_thread_levels_empty(): Unused function; remove.
trx_t: Remove mysql_thread_id and mysql_process_no.
srv_slot_t: Remove id and handle.
srv_conc_exit_innodb(), srv_suspend_mysql_thread: Assert
rb:634 approved by Sunny Bains
I do not know if there is a way to get this directly from Launchpad, probably not.
> Second, is there no
> way to get the OS thread id now? It was very handy when tying MySQL
> thread id to OS thread id for debugging with gdb.
I don't know of any easy way, it looks like the thread id was removed from the
Note that the bug referenced is in the new internal bug tracker, which is not
accessible. And the WL#5136 is marked private. Welcome to the new style of
Open Source development in MySQL ... but maybe an Oracle developer will
comment, some of them are quite helpful.
If I should guess, this is in preparation of better support for thread pool. I
heard rumours of a (closed-source) thread pool being developed at Oracle. With
a good thread pool, different statements in the same transaction can run in
different OS threads (or potentially even different parts of a single
statement), so I guess it no longer makes as much sense to associate a single
OS thread ID with a transaction.
Hope this helps,