Introduce a counter for protection against global read lock on thread level.

The functions for protection against global read lock sometimes need a local
variable to signal when the protection is set, and hence need to be released.
It would be better to control this behaviour via a counter on the THD struct,
telling how many times the protection has been claimed by the current thread.
A side-effect of the fix is that if protection is claimed twice for a thread,
only a simple increment is required for the second claim, instead of a
mutex-protected increment of the global variable protect_against_global_read_lock.

---------------------------------------------

This is a patch for bug#47098 assert in MDL_context::destroy on
HANDLER <damaged merge table> OPEN.
      
The assert occurs in MDL_context::destroy when the connection is terminated,
because all mdl_tickets have not been released.
MERGE tables do not support being opened using the HANDLER ... OPEN command,
and trying to do so will result in an error. In the event of an error, all
tables that are opened, should be closed again. The fix for bug#45781 made
sure that this also works for MERGE tables, which causes multiple tables to
be opened.
This fix extends the fix for bug#45781, by ensuring that also all locks are
released, when MERGE tables are involved.

Bug #21793 Missing CF_CHANGES_DATA and CF_STATUS_COMMAND for 
           handful of commands

CF_CHANGES_DATA and CF_STATUS_COMMAND flags added to the 
commands mentioned in the bug description. With the following
two exceptions: 

1) 4 commands do not exist: 
SQLCOM_RENAME_DB
SQLCOM_LOAD_MASTER_DATA
SQLCOM_LOAD_MASTER_TABLE
SQLCOM_SHOW_COLUMN_TYPES

2) All SQLCOM_SHOW_* commands already had CF_STATUS_COMMAND,
leaving only SQLCOM_BINLOG_BASE64_EVENT.

Further, check_prepared_statement() in sql_prepare.cc has been
simplified by taking advantage of the CF_STATUS_COMMAND flag.

Note that no test case has been added.

Bug #48248 assert in MDL_ticket::upgrade_shared_lock_to_exclusive

The assert would happen if REPAIR TABLE was used on a table already
locked by LOCK TABLES READ. REPAIR mistakenly tried to upgrade the
read-lock to exclusive, thereby triggering the assert.

The cause of the problem was that REPAIR TABLE ignored errors 
from opening and locking tables. This is by design, as REPAIR
can be used to broken tables that cannot be opened. However,
repair also ignored logical errors such as the inability to
exclusivly lock a table due to conflicting LOCK TABLES.

This patch fixes the problem by not ignoring errors from
opening and locking tables if inside LOCK TABLES mode.
In LOCK TABLES we already know that the table can be opened,
so that the failure to open must be a logical error.

Test added to repair.test.

Bug#47107

Add missing line in previous change set.

Bug #47107 assert in notify_shared_lock on incorrect CREATE TABLE , HANDLER

Attempts to create a table (using CREATE TABLE, CREATE TABLE LIKE or
CREATE TABLE SELECT statements) which already existed and was opened
by the same connection through HANDLER statement, led to a stalled
connection (for production builds of the server) or to the server being
aborted due to an assertion failure (for debug builds of the server).

This problem was introduced by the new implementation of a metadata
locking subsystem and didn't affect earlier versions of the server.

The cause of the problem was that the HANDLER was not closed by CREATE TABLE
before CREATE tried to open and lock the table. Acquiring an exclusive MDL
lock on the table to be created would therefore fail since HANDLER
already had a shared MDL lock. This triggered an assert as the 
HANDLER and CREATE statements came from the same thread (self-deadlock).

This patch resolves the issue by closing any open HANDLERs on tables
to be created by CREATE TABLE, similar to what is already done for 
DROP and ALTER TABLE.

Test case added to create.test.

Bug #48725 Assert !thd->is_error() in delayed_get_table()

This bug is a regression introduced by the patch for Bug #45949.

If the handler thread for INSERT DELAYED was killed by e.g.
FLUSH TABLES, the error message is copied from the handler thread
to the connection thread. But the error was not reacted on, so the
connection thread continued as normal, leading to an eventual assert.

No test case added as it would have required sync points to work
for handler threads. The plan is to add this in the scope of 
Bug #48725 / Bug #48541. The patch has been tested with the 
non-deterministic test case given in the bug description.

Bug #45949 Assertion `!tables->table' in open_tables() on 
           ALTER + INSERT DELAYED

The assertion was caused by improperly closing tables when 
INSERT DELAYED needed to reopen tables. This patch replaces
the call to close_thread_tables with close_tables_for_reopen
which fixes the problem.

The only way I was able to trigger the reopen code path and 
thus the assertion, was if ALTER TABLE killed the delayed
insert thread and the delayed insert thread was able to enter
the reopen code path before it noticed that thd->killed had
been set. Note that in these cases reopen will always fail 
since open_table() will check thd->killed and return. This patch
therefore adds two more thd->killed checks to minimize the 
chance of entering the reopen code path without hope for success.

The patch also changes it so that if the delayed insert is killed
using KILL_CONNECTION, the error message that is copied to the
connection thread is ER_QUERY_INTERRUPTED rather than 
ER_SERVER_SHUTDOWN. This means that if INSERT DELAYED fails, 
the user will now see "Query execution was interrupted" rather
than the misleading "Server shutdown in progress".

No test case is supplied. This is for two reasons:
1) Unable to reproduce the error without having the delayed insert
thread in a killed state which means that reopen is futile and
was not supposed to be attempted.
2) Difficulty of using sync points in other threads than 
the connection thread.
The patch has been successfully tested with the RQG and the grammar
supplied in the bug description.

Bug #47249 assert in MDL_global_lock::is_lock_type_compatible

This assert could be triggered if LOCK TABLES were used to lock
both a table and a view that used the same table. The table would have
to be first WRITE locked and then READ locked. So "LOCK TABLES v1
WRITE, t1 READ" would eventually trigger the assert, "LOCK TABLES
v1 READ, t1 WRITE" would not. The reason is that the ordering of locks
in the interal representation made a difference when executing 
FLUSH TABLE on the table.

During FLUSH TABLE, a lock was upgraded to exclusive. If this lock
was of type MDL_SHARED and not MDL_SHARED_UPGRADABLE, an internal
counter in the MDL subsystem would get out of sync. This would happen
if the *last* mention of the table in LOCK TABLES was a READ lock.

The counter in question is the number exclusive locks (active or intention). 
This is used to make sure a global metadata lock is only taken when the 
counter is zero (= no conflicts). The counter is increased when a
MDL_EXCLUSIVE or MDL_SHARED_UPGRADABLE lock is taken, but not when 
upgrade_shared_lock_to_exclusive() is used to upgrade directly
from MDL_SHARED to MDL_EXCLUSIVE. 

This patch fixes the problem by searching for a TABLE instance locked
with MDL_SHARED_UPGRADABLE or MDL_EXCLUSIVE before calling
upgrade_shared_lock_to_exclusive(). The patch also adds an assert checking
that only MDL_SHARED_UPGRADABLE locks are upgraded to exclusive.

Test case added to lock_multi.test.

------------------------------------------------------------
revno: 2617.69.32
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-next-bg46747
timestamp: Wed 2009-08-19 18:12:27 +0400
message:
  Fix for bug #46747 "Crash in MDL_ticket::upgrade_shared_lock_to_exclusive
  on TRIGGER + TEMP table".

  Server crashed when one tried to drop trigger which had its subject
  table shadowed by a temporary table with the same name.

  This problem occured because in such situation DROP TRIGGER has opened
  temporary table instead of base table on which trigger was defined.
  Attempt to upgrade metadata lock on this temporary table led to crash
  (we don't acquire metadata locks for temporary tables).

  This fix ensures that DROP TRIGGER ignores temporary tables when
  trying to open table on which trigger to be dropped is defined.

revno: 2617.69.33
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-next-46452
timestamp: Wed 2009-08-19 18:39:31 +0400
message:
  Bug#46452 "Crash in MDL, HANDLER OPEN + TRUNCATE TABLE".
  Flush open HANDLER tables before TRUNCATE, which is a DDL.

----------------------------------------------------------
revno: 2617.69.28
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-azalea-bugfixing
timestamp: Tue 2009-08-18 15:27:35 +0400
message:
  An attempt to fix a link failure on Windows -- Sroutine_hash_entry
  is forward-declared as class.
(Part of WL#4284).

----------------------------------------------------------
revno: 2617.69.25
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-42546
timestamp: Fri 2009-08-14 23:52:00 +0400
message:
  A cleanup in open_tables() and lock_tables():
  change return type of these functions to bool from int,
  to follow convention in the rest of the code.
(Part of WL#4284 review fixes).

A pre-requisite patch for Bug#30977 "Concurrent statement using 
stored function and DROP FUNCTION breaks SBR".

This patch changes the MDL API by introducing a namespace for
lock keys: MDL_TABLE for tables and views and MDL_PROCEDURE
for stored procedures and functions. The latter is needed for
the fix for Bug#30977.

Bug #42074 concurrent optimize table and 
           alter table = Assertion failed: thd->is_error()

This assertion could occur if OPTIMIZE TABLE was started on a InnoDB table
and the table was altered to different storage engine after OPTIMIZE
had started. This allowed OPTIMIZE to pass the initial checks for 
storage engine support, but fail once it reached "recreate+analyze"
if this operation was not supported by the new storage engine.
The bug had no consequences for non-debug builds of the server.

In detail, the assertion was triggered when ha_analyze() returned 
HA_ADMIN_NOT_IMPLEMENTED. This led to a code path which included an 
assert checking for diagnostics area contents. Since this area had 
not been filled, the assertion was triggered. The diagnostics area 
is in this case only used to provide more detailed information about 
why optimize failed. The triggered code path sends this information 
to the client and clears the diagnostic area.

This patch fixed the problem by adding an error message to the diagnostic 
area if ha_analyze() fails. This error message contains the error code
returned by ha_analyze().

Test case added to innodb_mysql_sync.test.

Bug #43272 HANDLER SQL command does not work under LOCK TABLES

HANDLER commands are now explicitly disallowed in LOCK TABLES mode.

Before, HANDLER OPEN gave the misleading error message: "Table x was 
not locked with LOCK TABLES". This patch changes HANDLER OPEN/READ/CLOSE 
to give ER_LOCK_OR_ACTIVE_TRANSACTION "Can't execute the given command 
because you have active locked tables or an active transaction" in
LOCK TABLES mode.

Test case added to lock.test.

Bug #45067 Assertion `stmt_da->is_error()' in 
           Delayed_insert::open_and_lock_table

The assert was triggered when delayed insert was killed by another 
connection using mysql_notify_thread_having_shared_lock().
During handling of thd->killed, thd.fatal_error() was called without
a previous call to my_error() which triggered the assert.
This patch allows the assert to pass if thd->killed has been set.

----------------------------------------------------------
revno: 2617.69.24
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-42546
timestamp: Fri 2009-08-14 19:22:05 +0400
message:
  A pre-requisite for a fix for Bug#42546 "Backup: RESTORE fails, thinking it
  finds an existing table"
  Back-port from WL 148 "Foreign keys" feature tree a patch
  that introduced Prelocking_strategy class -- a way to parameterize
  open_tables() behaviour, implemented by Dmitry Lenev.

(Part of WL#4284).

----------------------------------------------------------
revno: 2617.69.21
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-4284-1-assert
timestamp: Thu 2009-08-13 20:13:55 +0400
message:
  A fix and a test case for Bug#46610 "MySQL 5.4.4: MyISAM MRG engine crash
  on auto-repair of child".
  Also fixes Bug#42862 "Crash on failed attempt to open a children of a
  merge table".

  MERGE engine needs to extend the global table list
  with TABLE_LIST elements for child tables,
  so that they are opened and locked.
  Previously these table list elements were allocated
  in memory of ha_myisammrg object (MERGE engine handler).
  That would lead to access to freed memory in
  recover_from_failed_open_table_attempt(), which would
  try to recover a MERGE table child (MyISAM table)
  and use for that TABLE_LIST of that child.
  But by the time recover_from_failed_open_table_attempt()
  is invoked, ha_myisammrg object that owns this
  TABLE_LIST may be destroyed, and thus TABLE_LIST
  memory freed.

  The fix is to ensure that TABLE_LIST elements
  that are added to the global table list (lex->query_tables)
  are always allocated in thd->mem_root, which is not
  destroyed until end of execution.

  If previously TABLE_LIST elements were allocated
  at ha_myisammrg::open() (i.e. when the TABLE
  object was created and added to the table cache),
  now they are allocated in ha_myisammrg::add_chidlren_list()
  (i.e. right after "open" of the merge parent in
  open_tables()).
  We still create a list of children names
  at ha_myisammrg::open() to use as a basis
  for creation of TABLE_LISTs, that allows
  to avoid reading the merge handler data
  file on every execution.

Bug #22876 Four-way deadlock

This bug was fixed as a part of Bug#989 
"If DROP TABLE while there's an active transaction, wrong binlog order"
A statement which would have caused circular wait will now 
be aborted with ER_LOCK_DEADLOCK.

Test case based on bug description added to innodb_mysql_lock.test.
Note that innodb_lock_wait_timeout is set to 5 mins to 
prevent race conditions in the test.

Bug #39675 rename tables on innodb tables with pending 
           transactions causes slave data issue

Bug was already fixed as part of patch for Bug#989 
(If DROP TABLE while there's an active transaction, 
wrong binlog order) 

Test case added to rpl_innodb.test.

Bug #45066 FLUSH TABLES WITH READ LOCK deadlocks against LOCK TABLE

Test coverage for combinations of LOCK TABLE READ / WRITE and 
FLUSH TABLES / FLUSH TABLES WITH READ LOCK added to lock.test.
LOCK and FLUSH are executed sequentially from one connection.

----------------------------------------------------------
revno: 2617.69.20
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-4284-1-assert
timestamp: Thu 2009-08-13 18:29:55 +0400
message:
  WL#4284 "Transactional DDL locking"
  A review fix.
  Since WL#4284 implementation separated MDL_request and MDL_ticket,
  MDL_request becamse a utility object necessary only to get a ticket.
  Store it by-value in TABLE_LIST with the intent to merge
  MDL_request::key with table_list->table_name and table_list->db
  in future.
  Change the MDL subsystem to not require MDL_requests to
  stay around till close_thread_tables().
  Remove the list of requests from the MDL context.
  Requests for shared metadata locks acquired in open_tables()
  are only used as a list in recover_from_failed_open_table_attempt(),
  which calls mdl_context.wait_for_locks() for this list.
  To keep such list for recover_from_failed_open_table_attempt(),
  introduce a context class (Open_table_context), that collects
  all requests.
  A lot of minor cleanups and simplications that became possible
  with this change.

----------------------------------------------------------
revno: 2617.69.2
committer: Konstantin Osipov <kostja@sun.com>
branch nick: 5.4-azalea-bugfixing
timestamp: Mon 2009-08-03 19:26:04 +0400
message:
  A fix and a test case for Bug#45035 "Altering table under LOCK TABLES
  results in "Error 1213 Deadlock found...".

  If a user had a table locked with LOCK TABLES
  for READ and for WRITE in the same connection, ALTER TABLE
  could fail.

  Root cause analysis:

  If a connection issues

  LOCK TABLE t1 write, t1 a read, t1 b read;

  the new LOCK TABLES code in 6.0 (part of WL 3726) will create
  the following list of TABLE_LIST objects
  (thd->locked_tables_list->m_locked_tables):

  {"t1" "b" tl_read_no_insert}, {"t1" "a" tl_read_no_insert},
  {"t1" "t1" tl_write }

  Later on, when we try to ALTER table t1, mysql_alter_table()
  closes all TABLE instances and releases its thr_lock locks,
  keeping only an exclusive metadata lock on t1.

  But when ALTER is finished, Locked_table_list::reopen_tables()
  tries to restore the original list of open and locked tables.

  Before this patch, it used to do so one by one:
  Open t1 b, get TL_READ_NO_INSERT lock,
  Open t1 a, get TL_READ_NO_INSERT lock
  Open t1, try to get TL_WRITE lock, deadlock.

  The cause of the deadlock is that thr_lock.c doesn't
  resolve the situation when the read list only consists
  of locks taken by the same thread, followed by this very
  thread trying to take a WRITE lock. Indeed, since
  thr_lock_multi always gets a sorted list of locks,
  WRITE locks always precede READ locks in the list
  to lock.

  Don't try to fix thr_lock.c deficiency, keep this
  code simple.
  Instead, try to take all thr_lock locks at once
  in ::reopen_tables().

------------------------------------------------------------
revno: 2617.65.6
committer: Dmitry Lenev <dlenev@mysql.com>
branch nick: mysql-azalea-bg39674
timestamp: Sat 2009-07-25 00:28:43 +0400
message:
  Fix for bug #39674 "On shutdown mdl_destroy() called before
  plugin_shutdown()".

  Attempt to shutdown PBXT engine plugin led to assertion failure
  caused by using already destroyed mutex in metadata locking
  subsystem.

  This problem stemmed from the fact that we MDL subsystem and
  table definition cache were deinitialized before plugin shutdown
  while PBXT plugin during its shutdown process accessed tables and
  therefore expected them to be in working shape.

  This patch solves this problem by moving deinitialization of
  these two subsystems after plugins are shut down.

  No test case is provided since such test case would require
  using PBXT or other plugin which accesses tables during its
  shutdown process.

------------------------------------------------------------
revno: 2617.43.3
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 40188-6.0
timestamp: Thu 2009-05-07 13:15:54 +0200
message:
Sort results as the file list of the database directory is not
sorted (MY_DONT_SORT).

(This is a follow-up fix for WL#4284).

------------------------------------------------------------
revno: 2617.31.7
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: mysql-6.0-runtime
timestamp: Wed 2009-03-25 19:22:00 -0300
message:
WL#4284: Transactional DDL locking

Post-merge fixes for test cases.

2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1
- initial changeset that introduced the fix for 
Bug#989 and follow up fixes for all test suite failures
introduced in the initial changeset. 
------------------------------------------------------------
revno: 2617.31.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Fri 2009-03-06 19:17:00 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking

Currently the MySQL server does not keep metadata locks on
schema objects for the duration of a transaction, thus failing
to guarantee the integrity of the schema objects being used
during the transaction and to protect then from concurrent
DDL operations. This also poses a problem for replication as
a DDL operation might be replicated even thought there are
active transactions using the object being modified.

The solution is to defer the release of metadata locks until
a active transaction is either committed or rolled back. This
prevents other statements from modifying the table for the
entire duration of the transaction. This provides commitment
ordering for guaranteeing serializability across multiple
transactions.

- Incompatible change:

If MySQL's metadata locking system encounters a lock conflict,
the usual schema is to use the try and back-off technique to
avoid deadlocks -- this schema consists in releasing all locks
and trying to acquire them all in one go.

But in a transactional context this algorithm can't be utilized
as its not possible to release locks acquired during the course
of the transaction without breaking the transaction commitments.
To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be
returned if a lock conflict is encountered during a transaction.

Let's consider an example:

A transaction has two statements that modify table t1, then table
t2, and then commits. The first statement of the transaction will
acquire a shared metadata lock on table t1, and it will be kept
utill COMMIT to ensure serializability.

At the moment when the second statement attempts to acquire a
shared metadata lock on t2, a concurrent ALTER or DROP statement
might have locked t2 exclusively. The prescription of the current
locking protocol is that the acquirer of the shared lock backs off
-- gives up all his current locks and retries. This implies that
the entire multi-statement transaction has to be rolled back.

- Incompatible change:

FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ
LOCK won't cause locked tables to be implicitly unlocked anymore.

----------------------------------------------------------
revno: 2617.23.22
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Wed 2009-03-04 23:29:16 +0300
message:
  WL#4284, "Transactional DDL locking": fix a Windows compilation warning.

------------------------------------------------------------
revno: 2617.23.23
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: mysql-6.0-runtime
timestamp: Thu 2009-03-05 18:39:58 -0300
message:
Fix for broken build: SHARED is defined by Solaris headers.

----------------------------------------------------------
revno: 2617.23.20
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Wed 2009-03-04 16:31:31 +0300
message:
  WL#4284 "Transactional DDL locking"
  Review comments: "Objectify" the MDL API.
  MDL_request and MDL_context still need manual construction and
  destruction, since they are used in environment that is averse
  to constructors/destructors.

----------------------------------------------------------
revno: 2617.23.19
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Tue 2009-03-03 01:20:44 +0300
message:
  Metadata locking: realign comments. No semantical changes,
  only enforce a bit of the coding style.
This is a review fix for WL#4284 "Transactional DDL locking".

------------------------------------------------------------
revno: 2617.23.18
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 4284-6.0
timestamp: Mon 2009-03-02 18:18:26 -0300
message:
Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
WL#4284: Transactional DDL locking

This is a prerequisite patch:

These changes are intended to split lock requests from granted
locks and to allow the memory and lifetime of granted locks to
be managed within the MDL subsystem. Furthermore, tickets can
now be shared and therefore are used to satisfy multiple lock
requests, but only shared locks can be recursive.

The problem is that the MDL subsystem morphs lock requests into
granted locks locks but does not manage the memory and lifetime
of lock requests, and hence, does not manage the memory of
granted locks either. This can be problematic because it puts the
burden of tracking references on the users of the subsystem and
it can't be easily done in transactional contexts where the locks
have to be kept around for the duration of a transaction.

Another issue is that recursive locks (when the context trying to
acquire a lock already holds a lock on the same object) requires
that each time the lock is granted, a unique lock request/granted
lock structure structure must be kept around until the lock is
released. This can lead to memory leaks in transactional contexts
as locks taken during the transaction should only be released at
the end of the transaction. This also leads to unnecessary wake
ups (broadcasts) in the MDL subsystem if the context still holds
a equivalent of the lock being released.

These issues are exacerbated due to the fact that WL#4284 low-level
design says that the implementation should "2) Store metadata locks
in transaction memory root, rather than statement memory root" but
this is not possible because a memory root, as implemented in mysys,
requires all objects allocated from it to be freed all at once.

This patch combines review input and significant code contributions
from Konstantin Osipov (kostja) and Dmitri Lenev (dlenev).

Add two more files to .bzrignore.

Add two more files to .bzrignore.

----------------------------------------------------------
revno: 2617.22.7
committer: Konstantin Osipov <kostja@sun.com>
branch nick: mysql-6.0-runtime
timestamp: Tue 2009-01-27 16:41:58 +0300
message:
  WL#4284 "Transactional DDL locking" review.
  Improve a comment.

revno: 2617.22.4
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: mysql-6.0-runtime
timestamp: Mon 2009-01-26 15:19:14 -0200
message:
Move checks for OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN to a separate
helper function.

------------------------------------------------------------
revno: 3035.4.1
committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
branch nick: 39897-6.0
timestamp: Thu 2009-01-15 12:17:57 -0200
message:
Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist

The problem is that relying on the "Table lock" thread state in
its current position to detect that a thread is waiting on a lock
is race prone. The "Table lock" state change happens before the
thread actually tries to grab a lock on a table.

The solution is to move the "Table lock" state so that its set
only when a thread is actually going to wait for a lock. The state
change happens after the thread fails to grab the lock (because it
is owned by other thread) and proceeds to wait on a condition.

This is considered part of work related to WL#4284 "Transactional
DDL locking"
Warning: this patch contains an incompatible change. 
When waiting on a lock in thr_lock.c, the server used to display "Locked"
processlist state. After this patch, the state is "Table lock".
The new state was actually intended to be display since year 2002,
when Monty added it. But up until removal of thd->locked boolean
member, this state was ignored by SHOW PROCESSLIST code.  

-----------------------------------------------------------
2497.479.10 Sergei Golubchik    2008-08-27
            proc_info_hook, mysys access to thd->proc_info

This patch is necessary for backport of WL#4284 "Transactional
DDL locking".