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()
Since UNIONs that would allow a column to be masked are
rejected, there is no need to check that masking is performed
since we will never get that far.
It is an error to register the same task multiple times, but
for a maintenance release it is simpler and less risky to simply
ignore an attempt (that BLR does) to do that.
Allowing a task to be registered anew causes behaviour akin
to a leak.
This makes iterating over packets in buffers faster while still
maintaining the requirements for forward iterators. Not using operator+=
makes it clear that this is not a random access iterator.
Necessary if the firewall should be able to block columns when
'ANSI_QUOTES' as enabled and " instead of backticks are used.
Without this, the following
> set @@sql_mode='ANSI_QUOTES';
> select "ssn" from person;
will not be blocked if the database firewall has been configured
to block the column ssn.
Before this change, if the firewall was configured to block the use
of certain columns, it could be be bypassed simply by
> set @@sql_mode='ANSI_QUOTES';
> select "ssn" from person;
The reason is that as the query classifier is not aware of whether
'ANSI_QUOTES' is on or not, it will not know that what above appears
to be the string "ssn", actually is the field name `ssn`. Consequently,
the select will not be blocked and the result returned in cleartext.
It's now possible to instruct the query classifier to report all strings
as fields, which will prevent the above. However, it will also mean that
there may be false positives.
