If a result consists of only OK packets, they would be processed
recursively which most of the time leads to a stack overflow. This can be
prevented by consuming all OK packets in the result in one go.
- Check textual prepared statements for use of columns to be masked
in conjunction with functions.
- Check binary prepared statements for use of columns to be masked
in conjunction with functions.
- Prevent creation of textual prepared statement from variable.
As the masking filter must reject statements that use columns to be
masked as arguments to functions, a statement that cannot be fully
parsed must be rejected. Unless a statement can be fully parsed we
cannot know whether such usage occurs.
By always setting the position of the next event, the replication cannot
break if the slave server has to reconnect after receiving an event that
was generated by the binlogfilter.
Given the following query:
PREPARE ps FROM 'PREPARE ps2 FROM \'SELECT 1\'';
The debug assertion is hit even though this is valid, albeit unsupported,
SQL. An optimization would be to ignore the query if the prepared
statement type is another prepared statement.
When a single GWBUF was split into two with gwbuf_split, the new GWBUF
would point to the start of the shared data and the old one to the
end. Data-wise, this is fine but as the parsing info for queries is stored
in the shared buffer it causes problems when multiple packets get read in
one network payload. The end result would be that only the first query in
the lot would get parsed and the rest would get the same classification as
the first one.
To properly fix this without the need to deep clone the buffer would
require a reorganization of the buffer mechanism in MaxScale.
This commit alone doesn't fix the queued query routing problems in
readwritesplit. The commit from 2.2 which fixes the ordering problems with
queued queries is also required for a fully functional queued query
mechanism.
If a routing of a queued query caused it to be put back on the query
queue, the order in which the queue was reorganized was wrong. The first
query would get appended as the last query which caused the order to be
reversed.
Th discarding of connections in maintenance mode must be done after any
results have been written to them. This prevents closing of the connection
before the actual result is returned.
The candidate selection code used default values that would cause reads
past buffers. The code could also dereference the end iterator which
causes undefined behavior.
This fixes some situations where MaxAdmin/MaxCtrl would block and wait
until a monitor operation or tick is complete. This also fixes a deadlock
caused by calling monitor diagnostics inside a monitor script.
Concurrency is enabled by adding one mutex per server object to protect
array-like fields from concurrent reading/writing.
Queries in the query queue need to be explicitly parsed since they are
stored in a single buffer and thus share the query classification
information. In the next major version this should be changed into an
array of individual buffers instead of a shared buffer.
Always storing runtime configuration changes prevents problems when the
change causes another parameter to change. One example of this is
transaction_replay that implicitly enables other parameters.
If a DCB was closed and a hangup event was sent to it via
dcb_hangup_foreach shortly after it was closed, the DCB would still
receive it even if it was closed. To prevent this, events must only be
delivered to DCBs if they haven't been closed.
The protocol should not track the session state as the parsing is quite
expensive with the current code. This change is a workaround that enables
the parsing only when required. A proper way to handle this would be to do
all the response processing in one place thus avoiding the duplication of
work.
Given the fact that there exist only three possible categories, the map
can be replaced with a static array that needs no memory
allocations. Making this array thread-local allows it to be reused which
places an upper limit on the number of memory allocations.
The monitor now continuously updates a list of enabled server events. When
promoting a new master in failover/switchover, only events that were enabled
on the previous master are enabled on the new. This avoids enabling events
that may have been disabled on the master yet stayed in the SLAVESIDE_DISABLED-
state on the slave.
In the case of reset-replication command, events on the new master are only
enabled if the monitor had a master when the command was launched. Otherwise
all events remain disabled.
The documentation stated that at most `max_sescmd_history` commands were
kept but in reality the number of commands kept in the history was one
command smaller than what was documented.
If an ignorable packet was followed by more than one queued packets, they
would all get routed in the same batch. This would cause unexpected
replies from the server if multiple ignorable packets were queued up.
The default ECMAScript syntax appears to be broken on CentOS 7 which
effectively prevents its use in most cases. A more reliable alternative
would be to use the bundled PCRE2 library but the basic POSIX regular
expressions seem to work.
