when compiled with Sun Studio compiler).
The thing is that Sun Studio compiler calls destructor of stack
objects when pthread_exit() is called. That triggered an assertion
in DBUG_ENTER()/DBUG_RETURN() validation logic (if DBUG_ENTER() is
used in the beginning of function, all returns should be replaced
by DBUG_RETURN/DBUG_VOID_RETURN macros).
A fix is to explicitly use DBUG_LEAVE macro.
value from the index (PRIMARY)
With the fix for BUG#46760, we correctly flag the presence of row_type
only when it's actually changed and enables the FAST ALTER TABLE which was
disabled with the BUG#39200.
So the changes made by BUG#46760 makes MySQL data dictionaries to be out of
sync but they are handled already by InnoDB with this BUG#44030.
The test was originally written to handle this but we requested Innodb to
update the test as the data dictionaries were in sync after the fix for
BUG#39200.
Adjusting the innodb-autoinc testcase as mentioned in the comments.
When setting AUTOCOMMIT=1 after starting a transaction, the binary log
did not commit the outstanding transaction. The reason was that the binary
log commit function saw the values of the new settings, deciding that there
were nothing to commit.
Fixed the problem by moving the implicit commit to before the thread option
flags were changed, so that the binary log sees the old values of the flags
instead of the values they will take after the statement.
slave leaves slave unstable
Problem: when replicating from non-transactional to
transactional engine with autocommit off, no BEGIN/COMMIT
is written to the binlog. When the slave replicates, it
will start a transaction that never ends.
Fix: Force autocommit=on on slave by always replicating
autocommit=1 from the master.
> ------------------------------------------------------------
> revno: 3075
> revision-id: ramil@mysql.com-20090821055535-a5aeas33epokjjnp
> parent: joro@sun.com-20090820141122-gq6eyozybvar4o4s
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Fri 2009-08-21 10:55:35 +0500
> message:
> Fix for bug #46456 [Ver->Prg]: HANDLER OPEN + TRUNCATE + DROP
> (temporary) TABLE, crash
>
> Problem: if one has an open "HANDLER t1", further "TRUNCATE t1"
> doesn't close the handler and leaves handler table hash in an
> inconsistent state, that may lead to a server crash.
>
> Fix: TRUNCATE should implicitly close all open handlers.
>
> Doc. request: the fact should be described in the manual accordingly.
> ------------------------------------------------------------
> revno: 3044.1.1
> revision-id: kristofer.pettersson@sun.com-20090729200708-cb0td7n9r5md0aa0
> parent: davi.arnaut@sun.com-20090728195938-qabe9ldm2l4k8xns
> committer: Kristofer Pettersson <kristofer.pettersson@sun.com>
> branch nick: mysql-5.1-bugteam
> timestamp: Wed 2009-07-29 22:07:08 +0200
> message:
> Bug#44521 Executing a stored procedure as a prepared statement can sometimes cause
> an assertion in a debug build.
>
> The reason is that the C API doesn't support multiple result sets for prepared
> statements and attempting to execute a stored routine which returns multiple result
> sets sometimes lead to a network error. The network error sets the diagnostic area
> prematurely which later leads to the assert when an attempt is made to set a second
> server state.
>
> This patch fixes the issue by changing the scope of the error code returned by
> sp_instr_stmt::execute() to include any error which happened during the execution.
> To assure that Diagnostic_area::is_sent really mean that the message was sent all
> network related functions are checked for return status.
> ------------------------------------------------------------
> revno: 3019.1.3
> revision-id: ramil@mysql.com-20090714150729-xqv7aicsnoz6epy6
> parent: jimw@mysql.com-20090713191116-c8qxsrjagzbvbytj
> committer: Ramil Kalimullin <ramil@mysql.com>
> branch nick: b45998-5.1-bugteam
> timestamp: Tue 2009-07-14 20:07:29 +0500
> message:
> Fix for bug#45998: database crashes when running
> "create as select" (innodb table)
>
> Problem: code constructing "CREATE TABLE..." statement
> doesn't take into account that current database is not set
> in some cases. That may lead to a server crash.
>
> Fix: check if current database is set.
The "socket" variable is not available on Windows even though
the --socket option can be used to specify the pipe name for
local connections that use a named pipe.
The solution is to ensure that the variable is always defined.
