The problem appears often in conjuction with temp files, when temp-pool is used, so that names of temp files are not unique.

The reason is that rapid deletiion and creation of fiiles with the same name on Windows is not guaranteed to succeed. File disappears from the file system only when the last handle to it is closed. If for example  a virus scanner, a backup or indexing  application  opens the  temp file just before MySQL deletes it, the file will enter "delete pending" state. In this state,it is not possible to open the file , or create a file with the same name (CreateFile returns  ERROR_ACCESS_DENED, posix open returns EACESS)

Fix (rather a cheap workarounf) is not to use temp-pool when working with temporary files- this will make filenames unique. 
With this patch , temp- pool setting will be ignored on anything but Linux(the option only made sense for Linux since its invention anyway).

Uncommited changes are replicated and stay on slave after
rollback on master

Making test slightly more generic and robust.

                  
The problem here is that embedded server starts handle_thread manager 
thread  on mysql_library_init() does not stop it on mysql_library_end().
At shutdown, my_thread_global_end() waits for thread count to become 0,
but since we did not stop the thread it will give up after 5 seconds.
             
Solution is to move shutdown for handle_manager thread from kill_server()
(mysqld specific) to clean_up() that is used by both embedded and mysqld.
            
This patch also contains some refactorings - to avoid duplicate code,
start_handle_manager() and stop_handle_manager() functions are introduced.
Unused variables are eliminated. handle_manager does not rely on global
variable abort_loop anymore to stop (abort_loop is not set for embedded).
            
Note: Specifically on Windows and when using DBUG version of libmysqld, 
the complete solution requires removing obsolete code my_thread_init() 
from my_thread_var(). This has a side effect that a DBUG statement 
after my_thread_end() can cause thread counter to be incremented, and 
embedded will hang for some seconds. Or worse, my_thread_init() will 
crash if critical sections have been deleted by the global cleanup 
routine that runs in a different thread. 

This patch also fixes and revert prior changes for Bug#38293 
"Libmysqld crash in mysql_library_init if language file missing".

Root cause of the crash observed in Bug#38293  was bug in my_thread_init() 
described above

Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed


The both issues appeared to be a race between the SQL thread executing CREATE table t1
and the IO thread that is expected to stop at the consequent big size event.
The two events need serialization which is implemented.
The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.

after rollback on master

When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.

If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.

This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.

                    bigint' fails on windows.

Visual Studio does not take into account some x86 hardware limitations
which leads to incorrect results when converting large DOUBLE values
to BIGINT UNSIGNED ones.

Fixed by adding a workaround for double->ulonglong conversion on
Windows.

There was a missing initialization.

with non-RSA-requesting client if server uses RSA key

matchSuite() may not find a match. 
It will return error in this case.
Added a error checking code that will prevent using uninitialized 
memory in the code based on the assumption 
that matchSuite() has found a match.

                  
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.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

by using and taking out a full path.