into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

selected prior: ensure the fix also works for information_schema
tables.

Linux Debug build (possible deadlock)"

The bug is not repeatable any more.

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

incomplete in 5.0 (and review fixes).

When in 5.0.13 I introduced class Prepared_statement and methods
::prepare and ::execute, general logging was left out of this class.
This was good for stored procedures, since in stored procedures
we do not log sub-statements, but introduced a regression in case of SQL
syntax for prepared statements, as previously we would log the actual
statements to the log, and after the change we would log only
COM_QUERY text.

Restore the old behavior, but still suppress logging if inside a stored 
procedure.

Based on a community contributed patch from Vladimir Shebordaev.

No test case since we do not have a mechanism to test output
of the general log.

into  bodhi.(none):/opt/local/work/mysql-5.0-26141-final

causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table 
will block on X lock unnecessarily (duplciate).
Code review fixes.

Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently, 
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table. 

If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently. 
The problem had other side-effects (see respective bug reports).

This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.

The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime

A race condition in the integration between MyISAM and the query cache code 
caused the query cache to fail to invalidate itself on concurrently inserted
data.

This patch fix this problem by using the existing handler interface which, upon
each statement cache attempt, compare the size of the table as viewed from the 
cache writing thread and with any snap shot of the global table state. If the
two sizes are different the global table size is unknown and the current
statement can't be cached.

Fix the parser to make the database options not optional.

into  sita.local:/Users/tsmith/m/bk/maint/50

  Backport from 5.1 a fix to make this test deterministic

into  sita.local:/Users/tsmith/m/bk/maint/50

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-maint

into  sita.local:/Users/tsmith/m/bk/maint/50

into  sita.local:/Users/tsmith/m/bk/maint/50

into  sita.local:/Users/tsmith/m/bk/maint/41

into  sita.local:/Users/tsmith/m/bk/maint/50

into  mysql.com:/home/ram/work/b28808/b28808.5.0

into  sita.local:/Users/tsmith/m/bk/maint/50

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29417

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

An assertion abort could occur for some grouping queries that employed 
decimal user variables with assignments to them.

The problem appeared the constructors of the class Field_new_decimal
because the function my_decimal_length_to_precision did not guarantee
returning decimal precision not greater than DECIMAL_MAX_PRECISION.

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/4.1-opt

The cast operation ignored the cases when the precision and/or the scale exceeded
the limits, 65 and 30 respectively. No errors were reported in these cases.
For some queries this may lead to an assertion abort.

Fixed by throwing errors for such cases.

For GCov builds, if the server crashes, the normal exit handler for writing
coverage information is not executed due to the abnormal termination.

Fix this by explicitly calling the __gcov_flush function in our crash handler.

into  sita.local:/Users/tsmith/m/bk/maint/50

into  sita.local:/Users/tsmith/m/bk/maint/50

into  sita.local:/Users/tsmith/m/bk/maint/41

into  sita.local:/Users/tsmith/m/bk/maint/50

into  ppcg5.local:/private/Network/Servers/anubis.xiphis.org/home/antony/work/mysql-5.0-engines.merge

Merge ppcg5.local:/private/Network/Servers/anubis.xiphis.org/home/antony/work/mysql-4.1-engines.merge
into  ppcg5.local:/private/Network/Servers/anubis.xiphis.org/home/antony/work/mysql-5.0-engines.merge

into  anubis.xiphis.org:/usr/home/antony/work/mysql-5.0-engines.merge

into  anubis.xiphis.org:/usr/home/antony/work/mysql-4.1-engines.merge