It is all private. I can't get any details about Bug 12323643 from the
On Wed, Jul 6, 2011 at 10:59 AM, MARK CALLAGHAN <mdcallag@stripped> wrote:
> It is all private. I can't get any details about Bug 12323643 from the
> support site.
> On Wed, Jul 6, 2011 at 10:51 AM, Kristian Nielsen <knielsen@stripped>
>> ghazel@stripped writes:
>> > 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:
>> > http://bazaar.launchpad.net/~mysql/mysql-server/mysql-trunk/revision/3071
>> > First off, where can I find a real commit message?
>> bzr branch lp:mysql-server
>> bzr log -p --show-ids
>> revno: 3356
>> revision-id: marko.makela@stripped
>> parent: vasil.dimov@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
>> 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.
>> row_search_for_mysql(), srv_conc_enter_innodb(),
>> srv_conc_force_enter_innodb(), srv_conc_force_exit_innodb(),
>> 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
>> > 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
>> data structures.
>> 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,
>> - Kristian.
>> MySQL Internals Mailing List
>> For list archives: http://lists.mysql.com/internals
>> To unsubscribe: http://lists.mysql.com/internals?unsub=1
> Mark Callaghan