The function posix_fallocate() as well as the Linux system call
fallocate() can return EINTR when the operation was interrupted
by a signal. In that case, keep retrying the operation, except
if InnoDB shutdown has been initiated.
a large memory buffer on Windows
fil_extend_space_to_desired_size(), os_file_set_size(): Use calloc()
for memory allocation, and handle failures. Properly check the return
status of posix_fallocate().
On Windows, instead of extending the file by at most 1 megabyte at a time,
write a zero-filled page at the end of the file.
According to the Microsoft blog post
https://blogs.msdn.microsoft.com/oldnewthing/20110922-00/?p=9573
this will physically extend the file by writing zero bytes.
(InnoDB never uses DeviceIoControl() to set the file sparse.)
For innodb_plugin, port the XtraDB fix for MySQL Bug#56433
(introducing fil_system->file_extend_mutex). The bug was
fixed differently in MySQL 5.6 (and MariaDB Server 10.0).
The bug was that full memory barrier was missing in the code that ensures that
a waiter on an InnoDB mutex will not go to sleep unless it is guaranteed to be
woken up again by another thread currently holding the mutex. This made
possible a race where a thread could get stuck waiting for a mutex that is in
fact no longer locked. If that thread was also holding other critical locks,
this could stall the entire server. There is an error monitor thread than can
break the stall, it runs about once per second. But if the error monitor
thread itself got stuck or was not running, then the entire server could hang
infinitely.
This was introduced on i386/amd64 platforms in 5.5.40 and 10.0.13 by an
incorrect patch that tried to fix the similar problem for PowerPC.
This commit reverts the incorrect PowerPC patch, and instead implements a fix
for PowerPC that does not change i386/amd64 behaviour, making PowerPC work
similarly to i386/amd64.
- Reset static variables that are used to signal "init done" for DBUG, in dbug_end()
- Set string server variables to NULL after memory for the value is freed - avoids double free()
- fix DBUG_ASSERTs that happened during reinitialization.
Changed implementation os_file_rename() on Windows such as it does not fail if destination file already exists. Now MoveFileEx() with MOVEFILE_REPLACE_EXISTING flag is used, instead of prior MoveFile().
This fixed implementation is better compatible with rename() on POSIX systems.
- Better error messages
This fixes that one again can run the test systems with many threads without having to increase fs.aio-max-nr.
mysql-test/include/mtr_check.sql:
Ignore the INNODB_USE_NATIVE_AIO variable (may change during execution)
mysql-test/mysql-test-run.pl:
Ignore warnings for failure to setup AIO
storage/innobase/os/os0file.c:
Continue without AIO even if we can't allocate resources for AIO
storage/xtradb/os/os0file.c:
Continue without AIO even if we can't allocate resources for AIO
storage/xtradb/srv/srv0start.c:
Give an error message (instead of core dump) if AIO can't be initialized
Split IO threads into ones that handle only read completion and ones that handle only write completion, as it was originally done, but got lost with "completion port" patch. The reason we need to have dedicated read and dedicated write threads is that read completion routine can block waiting for write io to complete, and in rare cases where all io threads are handling async reads, it can deadlock.
sql/sql_insert.cc:
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
******
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
sql/sql_table.cc:
small cleanup
******
small cleanup
The reason for the long shutdown is hanging in io threads. It appears
that just closing completion port on XP does not necessarily signal
thread waiting in GetIOCompletionStatus() (even if this works fine
on later Windows versions)
The fix is to wakeup background threads using PostQueuedCompletionStatus()
with a special 'key' parameter indicating shutdown.
The reason for the crash is Innodb assertion after trying to load condition variables function
dynamically and not finding them
The fix is to skip dynamic loading if srv_use_native_conditions is FALSE. srv_use_native_conditions
is derived from Windows version and would be FALSE on XP and TRUE on later Windows.
This is the same handling as in MySQL 5.. In Maria 5.3 srv_use_native_conditions check was
presumably lost in the downporting.