The purpose is to recognize e.g. /_utf8mb4 0xD091D092D093/ as
a valid string. The rule actually accepts /id integer/, but in
case the statement is something else but an '_' immediately
followed by a character set, followed by a hex number, it will
be rejected by the server so no harm done.
During the build first binary packages are generated and copied into
'pre-repo' direcotory. Then binary repository is created and next
step is to copy repository into final directory according agreed
binary repo sirectories structure. After it temparal direcotries
are not needed.
The message now logs the instructions on how to increase the per-process
page limit for pipe buffers. This can happen if fs.pipe-max-size
multiplied by the number of workers exceeds the value of
fs.pipe-user-pages-soft multiplied by 4096.
Logging the pipe buffer size on startup will tell how large it was at the
time when MaxScale read it. If there are some abnormalities in it, this
will make it visible.
Logging the worker ID when the posting of a message fails will tell which
particular worker it was. For example, if the worker in question is the
main worker (i.e. ID 0), we know there's something that's blocking the
processing.
This allows the same verbose information to be logged in the cases where
it is of use. Mostly this information can be used to figure out why a
certain session was closed.
By doing the reconnection only when a new query arrives, we prevent the
excessive reconnecting that is done when a server's actual and monitored
states are in conflict.
With this change, a parenthesized top-level SELECT, such as
"(SELECT f FROM t)" will be fully parsed. Before this change,
the statement was classified as invalid and would thus have
been sent to the master.
With this change also statements like
(SELECT f FROM t1) UNION (SELECT f FROM t2)
will be correctly classified, although only partially parsed.
With these changes
SET @saved_cs_client= @@character_set_client;
will be classified as QUERY_TYPE_USERVAR_WRITE and
SELECT 1 AS c1 FROM t1 ORDER BY ( SELECT 1 AS c2 FROM
t1 GROUP BY GREATEST(LAST_INSERT_ID(), t1.a) ORDER BY
GREATEST(LAST_INSERT_ID(), t1.a) LIMIT 1);
will be classified as QUERY_TYPE_READ|QUERY_TYPE_MASTER_READ
In some configs /etc/my.cnf.d/* files access rights are
very limited and server can not read configuration.
It leads to broken settings and unability to setup
replication during the test
Because of how the user-data was read, the same service name could be
found multiple times if the user-search query matched multiple rows. Now
the service names are read to a set, which ignores duplicates. The same
service may be attempted again if the authentication fails and user-data
is fetched again.
The new server pam plugin does not always send the first password prompt with the
AuthSwitchRequest-packet. In this case the server expects the client (MaxScale) to
just send the password immediately. MaxScale now checks the length of the packet,
sending the password if the packet is short. This works with both old and new server
versions.
The test case covers a few bugs that were fixed by the previous
commits. The first part of the test covers the case when master
reconnection fails while session command history is being executed. The
second part of the test makes sure exceeding the session command history
will prevent master reconnections from taking place.
If a master failed during an ongoing session command history replay, it
would be treated as if a normal session command failed which would result
in the already executed session command being re-executed on all servers
at the wrong logical position.
To fix this, the history replay must be distinguished from normal session
command execution. When a connection replaying the history fails, the
query routing simply needs to be attempted again.
When a connection is created, the size of the history that is about to be
replayed is known. Storing this and decrementing it each time a session
command is completed tells us when the Backend has finished replaying the
session command history. This can then be used to distinguish whether a
session command executed on a master should be retried or whether to
simply discard the connection.
If session command execution during server reconnection caused a query to
be queued, the query would be put on the tail end of the queue. This would
cause queries to be reordered if the queue wasn't empty. The correct thing
to do would be to put the next pending query back at the front of the
queue.
If a master reconnection occurred after the session command history was
disabled due to the limit being exceeded, a debug assertion would be hit
in prepare_target. This assert makes sure that a connection can be safely
created to the server which means that in release mode builds the session
state would be inconsistent on the new master.
As this is an unrecoverable situation, the session should stop immediately
even if delayed_retry is enabled. Currently the session will continue
until the delayed retry timeout is hit. This happens due to the fact that
the delayed retry mechanism handles all errors in a similar way.
Now Docker is installed to VM which are used to build Maxscale. It allows to run tests which require Docker without installing it
during build process.
