type-of-operation-aware metadata locks and added a
wait-for graph based deadlock detector to the MDL
subsystem (this patch fixed bug #46272 "MySQL 5.4.4,
new MDL: unnecessary deadlock" and bug #37346
"innodb does not detect deadlock between update and
alter table").

Removed unused and redundant method.

of the TABLE_LIST instance, which did not initialize the 
MDL request properly.
Use init_one_table() to initialize the MDL request.

           failed in open_ltable()

The problem was too restrictive asserts that enforced that 
open_ltable() was called without any active HANDLERs, LOCK TABLES
or global read locks. 

However, this can happen in several cases when opening system
tables. The assert would, for example, be triggered when drop
function was called from a connection with active HANDLERs as
this would cause open_ltable() to be called for mysql.proc.
The assert could also be triggered when using table-based
general log (mysql.general_log).

This patch removes the asserts since they will be triggered in
several legitimate cases and because the asserts are no longer
relevant due to changes in how locks are released.

The patch also fixes set_needs_thr_lock_abort() that before 
ignored its parameter and always set the member variable to TRUE.

Test case added to mdl_sync.test.
Thanks to Dmitry Lenev for help with this bug!

Post merge fixes. In sys_vars tests suite, whenever we use LOCK TABLE WRITE,
adjust to lock the subject table indirecty via a view, to ensure that
there the desired lock conflict in thr_lock.c is still taking place.
If locked directly in LOCK TABLES list, thr_lock.c does not get
involved.
Adjust the thread wait state names in information_schema.processlist.

m_tickets.front() == m_trans_sentinel'".

Debug build of server crashed due to assert failure in MDL
subsystem when one tried to execute multi-table REPAIR or
OPTIMIZE in autocommit=0 mode.

The assert failure occured when multi-table REPAIR or OPTIMIZE
started processing of second table from its table list and
tried to acquire upgradable metadata lock on this table.
The cause of the assert failure were MDL locks left over from
processing of previous table. It turned out that in autocommit=0
mode close_thread_tables() which happens at the end of table
processing doesn't release metadata locks.

This fix solves problem by releasing locks explicitly using
MDL_context::release_trans_locks() call.

Fix Bug#50555 "handler commands crash server in my_hash_first()"
as a post-merge fix (the new handler tests are not passing 
otherwise).
- in hash.c, don't call calc_hash if ! my_hash_inited().
- add tests and results for the test case for Bug#50555

which implemented new type-of-operation-aware metadata
locks and added a wait-for graph based deadlock detector
to the MDL subsystem (this patch fixed bug #46272 "MySQL
5.4.4, new MDL: unnecessary deadlock" and bug #37346
"innodb does not detect deadlock between update and alter
table").

These hangs were caused by missing include of
wait_condition.inc. This fix simply adds them.

caused by patch which implemented new type-of-operation-aware
metadata locks and added a wait-for graph based deadlock
detector to the MDL subsystem (this patch fixed bug #46272
"MySQL 5.4.4, new MDL: unnecessary deadlock" and bug #37346
"innodb does not detect deadlock between update and alter
table").

Crashes were caused by a race in MDL_context::try_acquire_lock().
This method added MDL_ticket to the list of granted tickets and
released lock protecting list before setting MDL_ticket::m_lock.
Thus some other thread was able to see ticket without properly
set m_lock member for some short period of time. If this thread
called method involving this member during this period crash
happened.

This fix ensures that MDL_ticket::m_lock is set in all cases
when ticket is added to granted/pending lists in MDL_lock.

in a pointer arithmetics expression).

Add a wait-for graph based deadlock detector to the
MDL subsystem.

Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
bug #37346 "innodb does not detect deadlock between update and
alter table".

The first bug manifested itself as an unwarranted abort of a
transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
statement, when this transaction tried to repeat use of a
table, which it has already used in a similar fashion before
ALTER started.

The second bug showed up as a deadlock between table-level
locks and InnoDB row locks, which was "detected" only after
innodb_lock_wait_timeout timeout.

A transaction would start using the table and modify a few
rows.
Then ALTER TABLE would come in, and start copying rows
into a temporary table. Eventually it would stumble on
the modified records and get blocked on a row lock.
The first transaction would try to do more updates, and get
blocked on thr_lock.c lock.
This situation of circular wait would only get resolved
by a timeout.

Both these bugs stemmed from inadequate solutions to the
problem of deadlocks occurring between different
locking subsystems.

In the first case we tried to avoid deadlocks between metadata
locking and table-level locking subsystems, when upgrading shared
metadata lock to exclusive one.
Transactions holding the shared lock on the table and waiting for
some table-level lock used to be aborted too aggressively.

We also allowed ALTER TABLE to start in presence of transactions
that modify the subject table. ALTER TABLE acquires
TL_WRITE_ALLOW_READ lock at start, and that block all writes
against the table (naturally, we don't want any writes to be lost
when switching the old and the new table). TL_WRITE_ALLOW_READ
lock, in turn, would block the started transaction on thr_lock.c
lock, should they do more updates. This, again, lead to the need
to abort such transactions.

The second bug occurred simply because we didn't have any
mechanism to detect deadlocks between the table-level locks
in thr_lock.c and row-level locks in InnoDB, other than
innodb_lock_wait_timeout.

This patch solves both these problems by moving lock conflicts
which are causing these deadlocks into the metadata locking
subsystem, thus making it possible to avoid or detect such
deadlocks inside MDL.

To do this we introduce new type-of-operation-aware metadata
locks, which allow MDL subsystem to know not only the fact that
transaction has used or is going to use some object but also what
kind of operation it has carried out or going to carry out on the
object.

This, along with the addition of a special kind of upgradable
metadata lock, allows ALTER TABLE to wait until all
transactions which has updated the table to go away.
This solves the second issue.
Another special type of upgradable metadata lock is acquired
by LOCK TABLE WRITE. This second lock type allows to solve the
first issue, since abortion of table-level locks in event of
DDL under LOCK TABLES becomes also unnecessary.

Below follows the list of incompatible changes introduced by
this patch:

- From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
  statements that acquire TL_WRITE_ALLOW_READ lock)
  wait for all transactions which has *updated* the table to
  complete.

- From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
  (i.e. all statements which acquire TL_WRITE table-level lock) wait
  for all transaction which *updated or read* from the table
  to complete.
  As a consequence, innodb_table_locks=0 option no longer applies
  to LOCK TABLES ... WRITE.

- DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
  statements or transactions which use tables being dropped or
  renamed, and instead wait for these transactions to complete.

- Since LOCK TABLES WRITE now takes a special metadata lock,
  not compatible with with reads or writes against the subject table
  and transaction-wide, thr_lock.c deadlock avoidance algorithm
  that used to ensure absence of deadlocks between LOCK TABLES
  WRITE and other statements is no longer sufficient, even for
  MyISAM. The wait-for graph based deadlock detector of MDL
  subsystem may sometimes be necessary and is involved. This may
  lead to ER_LOCK_DEADLOCK error produced for multi-statement
  transactions even if these only use MyISAM:

  session 1:         session 2:
  begin;

  update t1 ...      lock table t2 write, t1 write;
                     -- gets a lock on t2, blocks on t1

  update t2 ...
  (ER_LOCK_DEADLOCK)

- Finally,  support of LOW_PRIORITY option for LOCK TABLES ... WRITE
  was abandoned.
  LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
  priority as the usual LOCK TABLE ... WRITE.
  SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE  in
  the wait queue.

- We do not take upgradable metadata locks on implicitly
  locked tables. So if one has, say, a view v1 that uses
  table t1, and issues:
  LOCK TABLE v1 WRITE;
  FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
  an error is produced.
  In order to be able to perform DDL on a table under LOCK TABLES,
  the table must be locked explicitly in the LOCK TABLES list.

condition variable per context instead of one mutex and one conditional
variable for the whole subsystem.

This should increase concurrency in this subsystem.

It also opens the way for further changes which are necessary to solve
such bugs as bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock"
and bug #37346 "innodb does not detect deadlock between update and alter
table".

Two other notable changes done by this patch:

- MDL subsystem no longer implicitly acquires global intention exclusive
  metadata lock when per-object metadata lock is acquired. Now this has
  to be done by explicit calls outside of MDL subsystem.
- Instead of using separate MDL_context for opening system tables/tables
  for purposes of I_S we now create MDL savepoint in the main context
  before opening tables and rollback to this savepoint after closing
  them. This means that it is now possible to get ER_LOCK_DEADLOCK error
  even not inside a transaction. This might happen in unlikely case when
  one runs DDL on one of system tables while also running DDL on some
  other tables. Cases when this ER_LOCK_DEADLOCK error is not justified
  will be addressed by advanced deadlock detector for MDL subsystem which
  we plan to implement.

           Diagnostics_area::set_ok_status at PREPARE

The problem occured during processing of stored routines. 
Routines are loaded from mysql.proc, parsed and put into the sp cache by
sp_cache_routine().  The assert occured because the return value from
sp_cache_routine() was not checked for top level CALLs. This meant that any
errors during sp_cache_routine() went unoticed and triggered the assert when
my_ok() was later called.

This is a regression introduced by the patch for Bug#30977, only visible in
source trees with MDL and using debug builds of the server.

This patch fixes the problem by checking the return value from sp_cache_routine() 
for top level CALLs and propagating any errors similar to what is done for other 
calls to sp_cache_routine().

No test case added.

The problem was that FLUSH TABLE <table_list> would block, 
waiting for all tables with old versions to be removed from 
the table definition cache, rather than waiting for only 
the tables in <table_list>. This could happen if FLUSH TABLE
was used in combination with LOCK TABLES.

With the new MDL code, this problem is no longer repeatable.
Regression test case added to lock.test. This commit contains
no code changes.

revno: 2762 [merge]
committer: Matthias Leich <mleich@mysql.com>
branch nick: mysql-6.0-bugteam-push
timestamp: Wed 2008-08-13 22:05:34 +0200
message:
  Upmerge 5.1 -> 6.0
    ------------------------------------------------------------
    revno: 2497.374.2
    committer: Matthias Leich <mleich@mysql.com>
    branch nick: mysql-5.1-bugteam-push
    timestamp: Wed 2008-08-13 21:44:54 +0200
    message:
      Fix for Bug#37853
          Test "funcs_1.processlist_val_ps" fails in various ways
      + corrections of logic in poll routines
      + minor improvements

This was a deadlock between LOCK TABLES/CREATE DATABASE in one connection
and DROP DATABASE in another. It only happened if the table locked by 
LOCK TABLES was in the database to be dropped. The deadlock is similar
to the one in Bug#48940, but with LOCK TABLES instead of an active
transaction.

The order of events needed to trigger the deadlock was:
1) Connection 1 locks table db1.t1 using LOCK TABLES. It will now
have a metadata lock on the table name.
2) Connection 2 issues DROP DATABASE db1. This will wait inside
the MDL subsystem for the lock on db1.t1 to go away. While waiting, it
will hold the LOCK_mysql_create_db mutex.
3) Connection 1 issues CREATE DATABASE (database name irrelevant).
This will hang trying to lock the same mutex. Since this is the connection
holding the metadata lock blocking Connection 2, we have a deadlock.

This deadlock would also happen for earlier trees without MDL, but 
there DROP DATABASE would wait for a table to be removed from the
table definition cache.

This patch fixes the problem by prohibiting CREATE DATABASE in LOCK TABLES
mode. In the example above, this prevents Connection 1 from hanging trying
to get the LOCK_mysql_create_db mutex. Note that other commands that use
LOCK_mysql_create_db (ALTER/DROP DATABASE) are already prohibited in 
LOCK TABLES mode.

Incompatible change: CREATE DATABASE is now disallowed in LOCK TABLES mode.

Test case added to schema.test.

Bug#45523 "Objects of class base_ilist should not be copyable".
               
Suppress the compiler-generated public copy constructor
and assignment operator of class base_ilist; instead, implement
move_elements_to() function which transfers ownership of elements
from one list to another.

Original revision:
------------------------------------------------------------
revno: 3817
revision-id: guilhem@mysql.com-20100108092756-k0zzf4kvx9b7bh38
parent: guilhem@mysql.com-20100107101133-hrrgcdqg508runuf
committer: Guilhem Bichot <guilhem@mysql.com>
branch nick: mysql-6.0-codebase-bugfixing
timestamp: Fri 2010-01-08 10:27:56 +0100
message:
  fix for BUG#50120 "Valgrind errors in any test, inside mysqltest"
  Problem was that as v->name[v->name_len] may be uninitialized (which is ok per se),
  it shouldn't be used in an if(). We remove this zero_the_char/restore_it logic by
  rather zero-terminating the v->name string when we create it in var_init().
------------------------------------------------------------

Original revision:

------------------------------------------------------------
revno: 3789.1.9
revision-id: serg@mysql.com-20091229134448-phe834ukzmi0k2e3
parent: serg@mysql.com-20091227081418-bgfg952gzumn1k3h
committer: Sergei Golubchik <serg@mysql.com>
branch nick: 6.0-codebase
timestamp: Tue 2009-12-29 14:44:48 +0100
message:
  better fix for Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
  
  use setenv instead of putenv
------------------------------------------------------------

                   INFILE".

Attempts to execute an INSERT statement for a MEMORY table which invoked
a trigger or called a stored function which tried to perform LOW_PRIORITY
update on the table being inserted into, resulted in debug servers aborting
due to an assertion failure. On non-debug servers such INSERTs failed with
"Can't update table t1 in stored function/trigger because it is already used
by statement which invoked this stored function/trigger" as expected.

The problem was that in the above scenario TL_WRITE_CONCURRENT_INSERT
is converted to TL_WRITE inside the thr_lock() function since the MEMORY
engine does not support concurrent inserts. This triggered an assertion
which assumed that for the same table, one thread always requests locks with
higher thr_lock_type value first. When TL_WRITE_CONCURRENT_INSERT is
upgraded to TL_WRITE after the locks have been sorted, this is no longer true.
In this case, TL_WRITE was requested after acquiring a TL_WRITE_LOW_PRIORITY
lock on the table, triggering the assert.

This fix solves the problem by adjusting this assert to take this
scenario into account.

An alternative approach to change handler::store_locks() methods for all engines
which do not support concurrent inserts in such way that
TL_WRITE_CONCURRENT_INSERT is upgraded to TL_WRITE there instead, 
was considered too intrusive.

Commit on behalf of Dmitry Lenev.

Part IV: sql instrumentation

Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.

Solution: do the subtraction on signed values.

eliminate 3 more "directory path" variables from the test's output (it was already
the case for other similar ones likes slow-query-log-file).

"set engine_condition_pushdown" is deprecated, engine condition pushdown is controlled
by a new "set optimizer_switch=engine_condition_pushdown=on|off".

fixing wrong indentation in two Makefile.am, which prevented the Anjuta IDE from parsing the MySQL tree.