To make it possible to have more tokens than 255.
Parsers operators (i.e. tokens) is one thing and opcodes
for the virtual machine of sqlite3 is another. Unfortunately
they are not completely separate, but some of the opcodes
in <build-directory>/opcodes.h are the same as the tokens in
<build-directory>/parse.h. And while the parser tokens are now
16-bit, the VM opcodes are 8-bit. However, this is probably not
a problem even if some of the parser tokens that are duplicated
in the opcodes are > 256 as we only use sqlite3 for parsing and
not for executing anything (on the sqlite3 VM).
The directory was created when the configuration was being processed and
it wasn't checked unless it was configured to a non-default value. With
the addition of the path validation, the directory must be created
earlier.
Responses generated by replayed session commands must not be treated as
actual responses to retained statements. In 2.5 this is not a problem as
it is done implicitly with the pre-assignment of the server that delivers
the session command response.
Doing the directory permission checks after all the values have been set
helps avoid problems with intermediate values that aren't valid. This
happens when --basedir generates invalid derived paths and the correct path
is provided as an argument right after it.
The path parameter is read from the configuration file only if it hasn't
been modified by a command line option. The case where an invalid command
line option is given but a valid configuration parameter would override it
is still treated as an error.
Also added a clarifying comment into set_dirs to make sure the handling
for the two path parameters is not moved inside set_runtime_dirs.
Fixed the testing scripts for the REST API and MaxCtrl now that the
directory permission checks are done correctly. Previously some paths seem
to have been ignored.
The original code for catenating an SrcList to another assumed
that the list to be catenated had only 1 element. Now works
regardless of the number of items.
The assumption that errno would be the same for the duration of the whole
call chain is wrong as it's possible that other calls that modify it are
made. Using the actual error string itself is much more reliable.
MaxCtrl seems to have relied on an implicit dependency which, for whatever
reason, broke only recently. Since we require() it, we should declare it
as a dependency.
Every change to MariaDB Enterprise should be tested with Maxscale.
Maxscale should be stable - installed from production repository.
New enviromental variable 'maxscale_product' is introduced.
It can be 'maxscale' or 'maxscale_ci' (default is 'maxscale_ci')
The LimitCORE command already sets the process core size limit so the
post-start command appears to be useless. In addition, it appears to fail
from time to time due to pidof failing to return the process ID of
MaxScale right as it starts. This in turn results in an unexplainable
failure to start with no messages logged anywhere with the exception of
the following from systemctl:
[vagrant@maxscale build]$ sudo systemctl status maxscale
● maxscale.service - MariaDB MaxScale Database Proxy
Loaded: loaded (/usr/lib/systemd/system/maxscale.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-12-16 21:16:55 CET; 26s ago
Process: 304024 ExecStartPost=/bin/sh -c prlimit -p $(pidof maxscale) --core=unlimited (code=exited, status=1/FAILURE)
Process: 304003 ExecStart=/usr/bin/maxscale (code=exited, status=0/SUCCESS)
Process: 304001 ExecStartPre=/usr/bin/install -d /var/lib/maxscale -o maxscale -g maxscale (code=exited, status=0/SUCCESS)
Process: 303999 ExecStartPre=/usr/bin/install -d /var/run/maxscale -o maxscale -g maxscale (code=exited, status=0/SUCCESS)
Main PID: 304004 (code=exited, status=0/SUCCESS)
