A query should not be queued if no responses are expected. The code that
executes queued queries should be dead code and this assertion would catch
it.
Older clients assume the plugin used for authentication is
mysql_native_password. If the client doesn't request plugin
authentication, don't treat it as an error.
The monitor queries for logged in users with super-privileges and kicks them out to
prevent writes to master. Normal users can stay since their writes are prevented by
read_only. Also, the master-status is removed from the master manually to signal to
routers that no more writes should go to master.
If the avro block is smaller than the size of the stored data, the file
was created with a block size that was too small. Even the reference Avro
implementation can't read the file in this case.
Plugins may send additional messages during authentication. These messages
often contain notifications such as password expiration dates. Both the client
and backend side authenticators now handle such messages. The messages are not
sent to the user, only the log. The requirement that only "Password: " is queried
still stands.
'build' and 'run_test' copies public ssh keys to all created VMs
Legacy code takes keys from different locations, e.g. ~/build-scripts/team_keys which
causes errors due to lack of such files.
Now public keys goes from file defined on or if not defined
from .ssh/id_rsa.pub of current host machine
The settings "match", "exclude" and "options" are now explained once
in the general documentation. The individual filter documentation refers
to the general explanation.
If a client requests an unknown binary protocol prepared statement handle,
a custom error shows the actual ID used instead of the "empty" ID of 0
that the backend sends.
The code that checked that only non-empty queries are stored in the query
queue was left out when the query queue fix was backported to 2.3. Since
MXS-2464 is caused by a still unknown bug, the runtime check should help
figure out in which cases the problem occurs.
mdbci call can heppen before maxsales object creation and segfault hapens
To avoid it call of ssh for 'maxscale --version-full' is moved to the end
of Testconnections constructor
log.cc:this_unit.slogger depends upon logger.cc:this_unit.ident.
Depending on which one is destructed first, there will be a crash
or then not.
It seems that the destruction order when returning from main()
is not necessarily the same as that when calling exit() in main,
as this bug is triggered with compilers versions and not with other.
Previously Maxscale version check was in the 'check_backend', but this was
removed from the tests execution process. Now 'maxscale --version-full'
is added to nodes creation function - to call_mdbci()
