The mon_ping_or_connect_to_db resets the MYSQL handle which caused the
loss of the error message. Returning a new enumeration value for
authentication errors solves this problem.
The code in 2.3 was changed to allow "empty" SSL definitions now that the
system CA is used. The code in 2.4 did not allow this which caused non-TLS
connections to be created when only ssl=true was defined.
This prevents empty or failed reads from updating the last_read flag which
in turn gives us the correct connection idle time when network errors
occur.
The code registered both client and backend callbacks for backend
DCBs. This caused the whole connection to hang if backend side throtting
was ever triggered.
The fix to the bug where peer certificates were validated but not required
caused the default behavior to change. The default should've changed at
the same time the fix was made.
The Connector-C was changed to always return only the client's charset,
not the actual charset that the connection ends up using. To cope with
this, the code has to use SQL to join the default character set name to
the default collation for it which can be used to extract the numeric ID
of the charset.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
Due to the fact that both client connections and listeners use sessions in
2.3, the client_count tracking must be done inside the client DCB. In
addition to this, the max_connections check didn't take the current
pending connection into account which caused an off-by-one error.
This commit fixes the connection_limit test failure that was introduced by
commit 6306519e5e75575ba083ee2f0edfe7e624da5d26.
By incrementing the counters when the session is created, we know that the
counter will always be decremented correctly. This does cause the listener
session to be counted as an actual session but this is already present in
the statistics calculations and is something we have to live with in 2.3
This change also makes it possible to overshoot the connection count
limitation as the session creation is delayed until authentication
fails. Both of these problems are fixed in 2.4.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
The FakeEventTask called the actual DCB handler with a fake task but it
didn't set the fake event flag. This caused KILL queries to be treated as
if they were network errors.
The password values are now masked with asterisks. This tells whether a
password is set or not but it does not expose any information about the
password itself.
The errors that are ignored by readwritesplit are now stored as the
current close reason in the Backend. This allows the information about the
error to be retained and it can be used later in the error handler to
display the true reason why the connection was closed.