The problem is that the query cache was storing partial results
if the statement failed when sending the results to the client.
This could cause clients to hang when trying to read the results
from the cache as they would, for example, wait indefinitely for
a eof packet that wasn't saved.

The solution is to always discard the caching of a query that
failed to send its results to the associated client.

This is not the final merge of that release build, but we need early
access to these tool fixes (use of "awk" in the BDB configuration).

with mysql_change_user) to 5.0.

Views weren't sync()d the same way other structures were.

In creating the FRM for views, obey the same rules for variable 
"sync_frm" as for everything else.

The problem is that the query cache stores packets containing
the server status of the time when the cached statement was run.
This might lead to a wrong transaction status in the client side
if a statement is cached during a transaction and is later served
outside a transaction context (and vice-versa).

The solution is to take into account the transaction status when
storing in and serving from the query cache.

The default "awk" there cannot handle some of the scripts
which are used by BDB for configuration.

The fix:
1) Introduce a variable "AWK" in some of the BDB shell scripts,
2) search "gawk" and give it precedence over "awk"
   when assigning a value to the "AWK" variable,
   fail if neither is found,
3) use that variable when calling an "awk" program with one
   of the critical scripts.

The perfect solution would be to use the "awk" program found
by "configure", but we cannot follow that approach because
BDB's configuration is handled as a special case before the
overall "configure" is run. Because of this,
1) the "configure" result isn't yet available,
2) "configure" will not handle these BDB files.
Searching "gawk" is a (not-so-nice) way out.

Note that all this need not be perfectly portable,
it is needed only when we create a source distribution tarball
from a develkopment tree.

      
The greedy optimizer tracks the current level of nested joins and the position
inside these by setting and maintaining a state that's global for the whole FROM
clause.
This state was correctly maintained inside the selection of the next partial plan
table (in best_extension_by_limited_search()). 
greedy_search() also moves the current position by adding the last partial match 
table when there's not enough tables in the partial plan found by 
best_extension_by_limited_search().
This may require update of the global state variables that describe the current
position in the plan if the last table placed by greedy_search is not a top-level 
join table.
Fixed by updating the state after placing the partial plan table in greedy_search()
in the same way this is done on entering the best_extension_by_limited_search().
Fixed the signature of the function called to update the state : 
check_interleaving_with_nj

Bug #39920: MySQL cannot deal with Leap Second expression in string literal.

Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds
during the leap second.

Original changesets:
> revision-id: kgeorge@mysql.com-20081201141835-rg8nnnadujj5wl9f
> parent: gshchepa@mysql.com-20081114172557-xh0jlzwal8ze3cy6
> committer: Georgi Kodinov <kgeorge@mysql.com>
> branch nick: B39920-5.0-bugteam
> timestamp: Mon 2008-12-01 16:18:35 +0200

> revision-id: kgeorge@mysql.com-20081201154106-c310zzy5or043rqa
> parent: kgeorge@mysql.com-20081201145656-6kjq91oga5nxbbob
> committer: Georgi Kodinov <kgeorge@mysql.com>
> branch nick: B39920-merge-5.0-bugteam
> timestamp: Mon 2008-12-01 17:41:06 +0200

Bug#34760 Character set autodetection appears to fail
the problem is the same as reported in bug#20835,
so the fix is backport of bug#20835 patch.

Original changeset:
> revision-id: sergey.glukhov@sun.com-20081121123959-58ffhp2nitg7f40h
> parent: ramil@mysql.com-20081120100836-gct60cm67b1rui29
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Fri 2008-11-21 16:39:59 +0400

BUG#38842 - Fix for 25951 seems incorrect

Original changeset:
> revision-id: svoj@mysql.com-20081111091051-54pr96nf1z2s30gx
> parent: vvaintroub@mysql.com-20081110201804-bi98gcs9avsf58ff
> committer: Sergey Vojtovich <svoj@mysql.com>
> branch nick: mysql-5.0-bugteam-bug38842
> timestamp: Tue 2008-11-11 13:10:51 +0400

Bug #40021: Renaming view fails, archived .frm for view is
            missing after downgrade

Original changeset:
> revision-id: gshchepa@mysql.com-20081114172557-xh0jlzwal8ze3cy6
> parent: ramil@mysql.com-20081114074229-vj4fvfrpmz8jfub9
> committer: Gleb Shchepa <gshchepa@mysql.com>
> branch nick: mysql-5.0-bugteam
> timestamp: Fri 2008-11-14 21:25:57 +0400

Remove bashisms from BUILD/compile-dist and configure.in,
so Bootstrap works on Solaris box;
- force GNU make in compile-dist;
- remove unportable "grep -q" from configure.in

Original changeset:
  revision-id: build@mysql.com-20081203041148-icwscut3bk09ds47
  parent: kgeorge@mysql.com-20081202125040-eiu6s7bk6s96s4xh
  author: timothy.smith@sun.com
  committer: MySQL Build Team <build@mysql.com>
  branch nick: mysql-5.0.74-release
  timestamp: Wed 2008-12-03 05:11:48 +0100

When substituting system constant functions with a constant result
the server was not expecting that the function may return NULL.
Fixed by checking for NULL and returning Item_null (in the relevant
collation) if the result of the system constant function was NULL.

Passing dubious "year zero" in non-zero date (not "0000-00-00") could
lead to negative value for year internally, while variable was unsigned.
This led to Really Bad Things further down the line.

Now doing calculations with signed type for year internally.

Added function to check for diff and return an error message if the utility is not present.
Previously, the way we did this didn't work on Windows, but did work on *Nix systems.

case.

Added global status variable 'Queries' which represents
total amount of queries executed by server including
statements executed by SPs.
note: It's old behaviour of 'Questions' variable.

Table could be marked dependent because it is
either 1) an inner table of an outer join, or 2) it is a part of
STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not
be assigned. The fix is to set st_table::maybe_null to 'true' only
for those tables which are used in outer join.