Backport of "Bug #50409 Solaris 8 compatibility broken by assumption about printstack() being present"

> ------------------------------------------------------------
> revno: 3345.2.1
> revision-id: joro@sun.com-20100218084815-53nb9oonzd7r4gmj
> parent: sergey.glukhov@sun.com-20100217121457-jqx19u6x387rgk7e
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: fix-5.1-bugteam
> timestamp: Thu 2010-02-18 10:48:15 +0200
> message:
>   Bug #51049: main.bug39022 fails in mysql-trunk-merge
>   
>   Fixed the test to behave correctly with ps-protocol
>   and binlog format row.

> ------------------------------------------------------------
> revno: 3333.1.6
> revision-id: joro@sun.com-20100129093628-sze9cv0neu0xbabm
> parent: davi.arnaut@sun.com-20100128215140-x0w6fe2de0b28opp
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B49552-5.1-bugteam
> timestamp: Fri 2010-01-29 11:36:28 +0200
> message:
>   Bug #49552 : sql_buffer_result cause crash + not found records
>     in multitable delete/subquery
>   
>   SQL_BUFFER_RESULT should not have an effect on non-SELECT 
>   statements according to our documentation.
>   Fixed by not passing it through to multi-table DELETE (similarly
>   to how it's done for multi-table UPDATE).

> ------------------------------------------------------------
> revno: 3333.1.31
> revision-id: joro@sun.com-20091223104518-o29t0i3thgs7wgm1
> parent: sergey.glukhov@sun.com-20100205093946-bx1hsljxlm12h7uf
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B39022-5.1-bugteam
> timestamp: Wed 2009-12-23 12:45:18 +0200
> message:
>   Bug #39022: Mysql randomly crashing in lock_sec_rec_cons_read_sees
>   
>   flush_cached_records() was not correctly checking for errors after calling
>   Item::val_xxx() methods. The expressions may contain subqueries
>   or stored procedures that cause errors that should stop the statement.
>   Fixed by correctly checking for errors and propagating them up the call stack.

> ------------------------------------------------------------
> revno: 3358
> revision-id: sergey.glukhov@sun.com-20100226113925-mxwn1hfxe3l8khc4
> parent: gshchepa@mysql.com-20100225191311-1x71dkk0h5e1alvx
> committer: Sergey Glukhov <Sergey.Glukhov@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Fri 2010-02-26 15:39:25 +0400
> message:
>   Bug#50995 Having clause on subquery result produces incorrect results.
>   The problem is that cond->fix_fields(thd, 0) breaks
>   condition(cuts off 'having'). The reason of that is
>   that NULL valued Item pointer is present in the
>   middle of Item list and it breaks the Item processing
>   loop.

Backporting of 5.1.43sp1 release, files mysql-test/r/bug39022.result, mysql-test/t/bug39022.test added

> ------------------------------------------------------------
> revno: 3333.1.11 [merge]
> revision-id: joro@sun.com-20100201115030-hgvq6489bt0w3rty
> parent: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
> parent: joro@sun.com-20100201114016-jylx4hivgqbs0vg2
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: test-5.1-bugteam
> timestamp: Mon 2010-02-01 13:50:30 +0200
> message:
>   merge
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.

> ------------------------------------------------------------
> revno: 3333.1.7 [merge]
> revision-id: ramil@mysql.com-20100129110849-1nm85j95594epnme
> parent: joro@sun.com-20100129093628-sze9cv0neu0xbabm
> parent: ramil@mysql.com-20100129091757-81r640na2t5bzbiz
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Fri 2010-01-29 15:08:49 +0400
> message:
>   Auto-merge.
> ------------------------------------------------------------
> Use --include-merges or -n0 to see merged revisions.

> ------------------------------------------------------------
> revno: 3329.2.3
> revision-id: svoj@sun.com-20100122095702-e18xzhmyll1e5s25
> parent: svoj@sun.com-20100122095632-j8ssd5csnlzp1zpf
> committer: Sergey Vojtovich <svoj@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Fri 2010-01-22 13:57:02 +0400
> message:
>   Applying InnoDB snapshot, fixes BUG#46193.
>   
>   Detailed revision comments:
>   
>   r6424 | marko | 2010-01-12 12:22:19 +0200 (Tue, 12 Jan 2010) | 16 lines
>   branches/5.1: In innobase_initialize_autoinc(), do not attempt to read
>   the maximum auto-increment value from the table if
>   innodb_force_recovery is set to at least 4, so that writes are
>   disabled. (Bug #46193)
>   
>   innobase_get_int_col_max_value(): Move the function definition before
>   ha_innobase::innobase_initialize_autoinc(), because that function now
>   calls this function.
>   
>   ha_innobase::innobase_initialize_autoinc(): Change the return type to
>   void.  Do not attempt to read the maximum auto-increment value from
>   the table if innodb_force_recovery is set to at least 4.  Issue
>   ER_AUTOINC_READ_FAILED to the client when the auto-increment value
>   cannot be read.
>   
>   rb://144 by Sunny, revised by Marko

> ------------------------------------------------------------
> revno: 3324
> revision-id: joro@sun.com-20091223151122-ada73up1yydh0emt
> parent: joro@sun.com-20100119124841-38vva51cuq3if7dc
> committer: Georgi Kodinov <joro@sun.com>
> branch nick: B49512-5.1-bugteam
> timestamp: Wed 2009-12-23 17:11:22 +0200
> message:
>   Bug #49512 : subquery with aggregate function crash
>     subselect_single_select_engine::exec()
>   
>   When a subquery doesn't need to be evaluated because
>   it returns only aggregate functions and these aggregates
>   can be calculated from the metadata about the table it
>   was not updating all the relevant members of the JOIN 
>   structure to reflect that this is a constant query.
>   This caused problems to the enclosing subquery 
>   ('<> SOME' in the test case above) trying to read some
>   data about the tables.
>   
>   Fixed by setting const_tables to the number of tables 
>   when the SELECT is optimized away.

> ------------------------------------------------------------
> revno: 3315.1.1
> revision-id: mattias.jonsson@sun.com-20100118164918-afjah8vmey4ya4ox
> parent: joro@sun.com-20100115090646-0g4tjrmqf20axlpv
> committer: Mattias Jonsson <mattias.jonsson@sun.com>
> branch nick: b47343-51-bt
> timestamp: Mon 2010-01-18 17:49:18 +0100
> message:
>   Bug#47343: InnoDB fails to clean-up after lock wait timeout on
>              REORGANIZE PARTITION
>   
>   There were several problems which lead to this this,
>   all related to bad error handling.
>   
>   1) There was several bugs preventing the ddl-log to be used for
>      cleaning up created files on error.
>   
>   2) The error handling after the copy partition rows did not close
>      and unlock the tables, resulting in deletion of partitions
>      which were in use, which lead InnoDB to put the partition to
>      drop in a background queue.

> ------------------------------------------------------------
> revno: 3325
> revision-id: mattias.jonsson@sun.com-20100119160251-0xvcgzw0y08xwk6r
> parent: joro@sun.com-20091223151122-ada73up1yydh0emt
> committer: Mattias Jonsson <mattias.jonsson@sun.com>
> branch nick: topush-51-bugteam
> timestamp: Tue 2010-01-19 17:02:51 +0100
> message:
>   post-push patch for bug#47343.
>   
>   Missing ha_rnd_end in copy_partitions, found due to a
>   DBUG_ASSERT in mysql-pe

> ------------------------------------------------------------
> revno: 3302.1.1
> revision-id: kristofer.pettersson@sun.com-20100113113900-o3m4jcm4l6qzum57
> parent: dao-gang.qu@sun.com-20091231040419-i5dnn06ahs256qcy
> committer: Kristofer Pettersson <kristofer.pettersson@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2010-01-13 12:39:00 +0100
> message:
>   Bug#33982 debug assertion and crash reloading grant tables after sighup or kill
>   
>   In certain rare cases when a process was interrupted
>   during a FLUSH PRIVILEGES operation the diagnostic
>   area would be set to an error state but the function
>   responsible for the operation would still signal
>   success. This would lead to a debug assertion error
>   later on when the server would attempt to reset the
>   DA before sending the error message.
>   
>   This patch fixes the issue by assuring that
>   reload_acl_and_cache() always fails if an error
>   condition is raised.
>   
>   The second issue was that a KILL could cause
>   a console error message which referred to a DA
>   state without first making sure that such a
>   state existed.
>   
>   This patch fixes this issue in two different
>   palces by first checking DA state before
>   fetching the error message.
>   
>    

Added not_embedded to the new dbug_sync test file.

Problem: When RAND() is binlogged in statement mode, the seed is
binlogged too, so the replication slave generates the same
sequence of random numbers. This makes replication work in many
cases, but not in all cases: the order of rows is not guaranteed
for, e.g., UPDATE or INSERT...SELECT statements, so the row data
will be different if master and slave retrieve the rows in
different orders.
Fix: Mark RAND() as unsafe. It will generate a warning if
binlog_format=STATEMENT and switch to row-logging if
binlog_format=ROW.

Problem: copying issuer's (or subject's) name tags into an internal
buffer from incoming stream we didn't check the buffer overflow. 
That may lead to memory overrun, crash etc.

Fix: ensure we don't overrun the buffer.

Note: there's no simple test case (exploit needed).

Selecting of the CONCAT_WS(...<PS parameter>...) result into
a user variable may return wrong data.

Item_func_concat_ws::val_str contains a number of memory
allocation-saving optimization tricks. After the fix
for bug 46815 the control flow has been changed to a
branch that is commented as "This is quite uncommon!":
one of places where we are trying to concatenate
strings inplace. However, that "uncommon" place
didn't care about PS parameters, that have another
trick in Item_sp_variable::val_str(): they use the
intermediate Item_sp_variable::str_value field,
where they may store a reference to an external
argument's buffer.

The Item_func_concat_ws::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return a
pointer to an internal Item member variable that
may reference to a buffer provided.

MySQL handles the join syntax "JOIN ... USING( field1,
... )" and natural joins by building the same parse tree as
a corresponding join with an "ON t1.field1 = t2.field1 ..."
expression would produce. This parse tree was not cleaned up
properly in the following scenario. If a thread tries to
lock some tables and finds that the tables were dropped and
re-created while waiting for the lock, it cleans up column
references in the statement by means a per-statement free
list. But if the statement was part of a stored procedure,
column references on the stored procedure's free list weren't
cleaned up and thus contained pointers to freed objects.

Fixed by adding a call to clean up the current prepared
statement's free list.

This includes "MYSQL_U_SCORE_VERSION" in "configure.in".

- "release" starts from 1
- "level" ("m2", "rc", ...) is included in the RPM version.

but don't take the "tree name" change.

- "release" starts from 1
- "level" ("m2", "rc", ...) is included in the RPM version.

32bit builds with the --enable-assembler flag (enabled by default)
fail with an error message: undefined reference to `strmov_overlapp'.

Since the fix for bug 48866 we use a home-grown strmov function
instead of the ctpcpy function, but the source file for this
function was missed in the Makefile.am.

The strings/Makefile.am file has been modified to include strmov.c
file into ASSEMBLER_x86 and ASSEMBLER_sparc32 sections.

Recover the right contents of the index file at the end of the test case.

Manually deleteing one or more entries from 'master-bin.index', will
cause master infinitely loop to send one binlog file. 

When starting a dump session, master opens index file and search the binlog file
which is being requested by the slave. The position of the binlog file in the
index file is recorded. it will be used to find the next binlog file when current
binlog file has dumped completely. As only the position is used, it may
not get the correct file if some entries has been removed manually from the index file.
the master will reopen the current binlog file which has been dump completely
and redump it if it can not get the next binlog file's name from index file.
It obviously is a logical error.


Even though it is allowed to manually change index file,
but it is not recommended. so after this patch, master
sends a fatal error to slave and close the dump session if a new binlog file
has been generated and master can not get it from the index file.

Fixed valgrind failure on PB2.

Fixed valgrind failure on PB2.

Fixed valgrind failure on PB2.