If the log file is successfully opened, both stdout and stderr are
redirected to it. This helps catch ASAN reports without having to read the
system journal files.
As the output is redirected to a file, some of the output was made visible
only in non-daemon mode. This helps keep the log file clean and readable.
The client connections had the Nagle algorithm enabled which could cause
bad performance with smaller workloads. The common network configuration
code in utils.cc, currently used by the backend connections, sets it
properly.
Clean up, comments and enhancements. StopWatch lap() didn't mean lap-time, but elapsed time. Changed meaning to lap-time and added split() for split-time.
Cherry-picking the commit from develop since it's also needed for 2.2.
FindASAN did not look for so version 5 and TSAN referred to ASAN. Disable
leak checks for unit tests as some objects always leak, namely servers.
The check for a closed session should never be needed as the core
correctly orders the calls to the module functions. The version numbering
was also not used.
Fixed the incrementation of the query counter so that it uses relaxed
atomic operations.
Replaced SPINLOCK with std::mutex where possible, leaving out the more
complex cases. The big offenders remaining are the binlogrouter and the
gateway.cc OpenSSL locks.
SELECT...FOR UPDATE locks the rows for update, but only if
autocommit==0 or a transaction is active, so in principle even if
it were classified as READ it'd still be sent to master when it
actually matters.
However, even if autocommit==1 and/or no transaction is active, a
slave in read only mode will reject the statement if the user is
subject to the read only restriction (a user with super privileges
is not), which might be considered a server bug. By classifying the
statement as a write, it'll be sent to master and always succeed.
In progress, does not yet overwrite existing code.
The new promotion mechanism automatically retries queries which timed out. It also
handles multimaster situations correctly.
Removed the almost equal comparison and subsequent selection based on historical number of connections.
The effect of it was this: Select the server that has historically, weights or not, been slower. Tested this with 2.2
with maxscale on one server and mariadb:s on two servers with different network lags. The tests with historical
selects were clearly slower.
