Use "#ifdef", not plain "#if".

The bug is a compilation issue:
Function "find_key_block()" had thread operations
which were not guarded by "#if THREAD", add that now.

can lead to bad memory access

Problem: Field_bit is the only field which returns INT_RESULT
and doesn't have unsigned flag. As it's not a descendant of the 
Field_num, so using ((Field_num *) field_bit)->unsigned_flag may lead
to unpredictable results.

Fix: check the field type before casting.

The pthread_cond_wait implementations for windows might
dead lock in some rare circumstances.

1) One thread (I) enter a timed wait and at a point in
   time ends up after mutex unlock and before
   WaitForMultipleObjects(...)
2) Another thread (II) enters pthread_cond_broadcast.
   Grabs the mutex and discovers one waiter. It set
   the broadcast event and closes the broadcast gate
   then unlocks the mutex.
3) A third thread (III) issues a pthread_cond_signal.
   It grabs the mutex, discovers one waiter, sets the
   signal event then unlock the mutex.
4) The first threads (I) enters WaitForMultipleObjects
   and finds out that the signal object is in a
   signalled state and exits the wait.
5) Thread (I) grabs the mutex and checks result status.
   The number of waiters is decreased and becomes equal
   to 0. The event returned was a signal event so the
   broadcast gate isn't opened. The mutex is released.
6) Thread (II) issues a new broadcast. The mutex is
   acquired but the number of waiters are 0 hence
   the broadcast gate remains closed.
7) Thread (I) enters the wait again but is blocked by
   the broadcast gate.

      This fix resolves the above issue by always resetting
      broadcast gate when there are no more waiters in th queue.

                    Removes the need of a hack (the jump to label).

On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.

The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.

The solution is to verify whether the thread has a associated
session before trying to detach a handle.

Make configure.js bail with an error if trying to build bdb from a bzr
tree.

          'flush tables' crashes

The server crashes when 'show procedure status' and 'flush tables' are
run concurrently.

This is caused by the way mysql.proc table is added twice to the list
of table to lock although the requirements on the current locking API
assumes differently.

No test case is submitted because of the nature of the crash which is 
currently difficult to reproduce in a deterministic way.

This is a backport from 5.1

> ------------------------------------------------------------
> revno: 2802.1.1
> tags: mysql-5.0.86
> revision-id: hery.ramilison@sun.com-20090909185217-mooeczu391ztp2fz
> parent: joro@sun.com-20090902123318-8qe40pr91xmui5ue
> committer: hery <hery.ramilison@sun.com>
> branch nick: mysql-5.0.86-release
> timestamp: Wed 2009-09-09 20:52:17 +0200
> message:
>   change c++ comment to c comment

> ------------------------------------------------------------
> revno: 2796
> revision-id: sergey.glukhov@sun.com-20090827102219-sgjz0v5t1rfccs14
> parent: joro@sun.com-20090824122803-1d5jlaysjc7a7j6q
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Thu 2009-08-27 15:22:19 +0500
> message:
>   Bug#46184 Crash, SELECT ... FROM derived table procedure analyze
>   The crash happens because select_union object is used as result set
>   for queries which have derived tables.
>   select_union use temporary table as data storage and if
>   fields count exceeds 10(count of values for procedure ANALYSE())
>   then we get a crash on fill_record() function.

> ------------------------------------------------------------
> revno: 2791.2.3
> revision-id: joro@sun.com-20090827114042-h55n7qp9990bl6ge
> parent: anurag.shekhar@sun.com-20090831073231-e55y1hsck6n08ux8
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B46749-5.0-bugteam
> timestamp: Thu 2009-08-27 14:40:42 +0300
> message:
>   Bug #46749: Segfault in add_key_fields() with outer subquery level 
>     field references
>   
>   This error requires a combination of factors : 
>   1. An "impossible where" in the outermost SELECT
>   2. An aggregate in the outermost SELECT
>   3. A correlated subquery with a WHERE clause that includes an outer 
>   field reference as a top level WHERE sargable predicate
>   
>   When JOIN::optimize detects an "impossible WHERE" it will bail out
>   without doing the rest of the work and initializations. It will not
>   call make_join_statistics() as well.  And make_join_statistics fills 
>   in various structures for each table referenced.
>   When processing the result of the "impossible WHERE" the query must
>   send a single row of data if there are aggregate functions in it.
>   In this case the server marks all the aggregates as having received 
>   no rows and calls the relevant Item::val_xxx() method on the SELECT
>   list. However if this SELECT list happens to contain a correlated 
>   subquery this subquery is evaluated in a normal evaluation mode.
>   And if this correlated subquery has a reference to a field from the 
>   outermost "impossible where" SELECT the add_key_fields will mistakenly
>   consider the outer field reference as a "local" field reference when 
>   looking for sargable predicates.
>   But since the SELECT where the outer field reference refers to is not
>   completely initialized due to the "impossible WHERE" in this level
>   we'll get a NULL pointer reference.
>   Fixed by making a better condition for discovering if a field is "local"
>   to the SELECT level being processed. 
>   It's not enough to look for OUTER_REF_TABLE_BIT in this case since 
>   for outer references to constant tables the Item_field::used_tables() 
>   will return 0 regardless of whether the field reference is from the 
>   local SELECT or not.

The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.

To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' 
in regardless of the database filtering rules.

          replication
              
MySQL server uses wrong lock type (always TL_READ instead of
TL_READ_NO_INSERT when appropriate) for tables used in
subqueries of UPDATE statement. This leads in some cases to
a broken replication as statements are written in the wrong
order to the binlog.

Add --help option.

   Solaris binary packages should be compiled with '-g0', not '-g'

 query
      
The fix for bug 46749 removed the check for OUTER_REF_TABLE_BIT 
and substituted it for a check on the presence of 
Item_ident::depended_from.
Removing it altogether was wrong : OUTER_REF_TABLE_BIT should 
still be checked in addition to depended_from (because it's not 
set in all cases and doesn't contradict to the check of depended_from).
Fixed by returning the old condition back as a compliment to the 
new one.

 - Create the "dummy" thread joinable and wait for it to
   exit before continuing in 'my_thread_global_init'
 - This way we know that the pthread library is initialized
   by one thread only

    Solaris binary packages should be compiled with '-g0', not '-g'

The main fix for this is done in the build tools,
but in the sources it affects "configure.in"
which sets "DEBUG_CXXFLAGS" to be used in all debug builds.

      
Initialize correctly client flags for the embedded client
Test cases in jp updated to work correctly with embedded server.