MARIADB-TEST-RUN(1)

📦
version 11.8.9 · 7 versions
, in alpine 3.24, centos-stream 10, centos-stream 9, debian trixie, fedora 43, fedora 44, nixpkgs unstable, opensuse-leap 16.0, ubuntu resolute, ubuntu stonking

🎀 NAME 🎀

Okay bestie, so this page — MARIADB-TEST-RUN(1), from the MariaDB Database System manual — is all about mariadb-test-run.pl, the script that runs the MariaDB test suite. That's the whole vibe. 💅

✨ SYNOPSIS ✨

mariadb-test-run.pl [options]

🦋 DESCRIPTION 🦋

So mariadb-test-run.pl is this Perl script, right? And it's the main application you use to run the MariaDB test suite. Basically it calls mariadb-test to run all the individual test cases one by one. Main character energy fr fr. 👑

You invoke it from inside the mariadb-test directory, like this:

shell> mariadb-test-run.pl [options] [test_name] ...

Every test_name argument is just the name of a test case, and the test case file that goes with a test name lives at t/test_name.test. Simple.

For each test_name you hand it, mariadb-test-run.pl runs that named test case. And if you give it no test_name arguments at all? It runs every .test file in the t subdirectory. All of them. Go off. 🎉

If you don't give a suffix for the test name, it assumes .test. Any leading path name? Straight up ignored. So these three commands are literally equivalent:

shell> mariadb-test-run.pl mytest
shell> mariadb-test-run.pl mytest.test
shell> mariadb-test-run.pl t/mytest.test

💖 Naming tests and suites 💖

You can also put a suite name in the test name. The syntax for naming a test is:

[suite_name.]test_name[.suffix]

If you do give a suite name, mariadb-test-run.pl looks in that suite for the test. So the test file for a test named suite_name.test_name lives at suite/suite_name/t/test_name.test. Also there's an implicit suite name main for the tests sitting in the top t directory. 🗂️

With no suite name given, mariadb-test-run.pl checks the default list of suites for a match and runs the test in any suites where it finds it. Example time: suppose your default suite list is main, binlog, rpl, and a test mytest.test exists in both the main and rpl suites. Pass mytest or mytest.test and it'll run mytest.test from main and rpl. Both of them. No cap.

🌈 Running a whole family of tests 🌈

Wanna run a whole family of test cases whose names share a common prefix? Use the --do-test=prefix option. Like, --do-test=rpl runs the replication tests (the test cases whose names begin with rpl). And --skip-test does the exact opposite — it skips the test cases whose names share a common prefix. 💫

Now, the argument for --do-test and --skip-test is actually flexible about which tests it performs or skips. Here's the tea: if the argument contains a pattern metacharacter other than a lone period, it gets interpreted as a Perl regular expression and applies to test names matching that pattern. If the argument contains a lone period, or has no pattern metacharacters at all, it's interpreted the same way as before — matching test names that begin with the argument value.

For example:

  • --do-test=testa matches tests that begin with testa
  • --do-test=main.testa matches tests in the main test suite that begin with testa
  • --do-test=main.*testa matches test names that contain main followed by testa with anything in between

In that last case, the pattern match is not anchored to the beginning of the test name, so it also matches names like xmainytesta. Sneaky, but iconic. 😭

🔥 Bootstrap setup and MYSQLD_BOOTSTRAP 🔥

To perform setup before running tests, mariadb-test-run.pl needs to invoke mariadbd with the --bootstrap and --skip-grant-tables options. But heads up — if MariaDB was configured with the --disable-grant-options option, then --bootstrap, --skip-grant-tables, and --init-file are all disabled. 😬

To handle that, set the MYSQLD_BOOTSTRAP environment variable to the full path name of a server that has all options enabled. mariadb-test-run.pl will use that server to perform setup — it is not used to run the tests. Just setup. That's it.

The init_file test will fail if --init-file is disabled. That's an expected failure, and you can handle it like this:

shell> export MYSQLD_BOOTSTRAP
shell> MYSQLD_BOOTSTRAP=/full/path/to/mariadbd
shell> make test force="--skip-test=init_file"

🫶 Running it on Windows 🫶

To run mariadb-test-run.pl on Windows, you'll need either Cygwin or ActiveState Perl. You may also need to install the modules the script requires. To actually run the test script: change location into the mariadb-test directory, set the MTR_VS_CONFIG environment variable to the configuration you selected earlier (or just use the --vs-config option), and invoke mariadb-test-run.pl. For example (using Cygwin and the bash shell):

shell> cd mariadb-test
shell> export MTR_VS_CONFIG=debug
shell> ./mariadb-test-run.pl --force --timer
shell> ./mariadb-test-run.pl --force --timer --ps-protocol

🌸 The environment variables bestie 🌸

mariadb-test-run.pl uses several environment variables. Some are listed in the following table — some of them get set from the outside and are used by mariadb-test-run.pl, and others are set by mariadb-test-run.pl instead, and may be referred to in tests. Both directions, we love a two-way street. 💖

  • MTR_VERSION — If set to 1, will run the older version 1 of mariadb-test-run.pl. This will affect what functionailty is available and what command line options are supported.
  • MTR_MEM — If set to anything, will run tests with files in "memory" using tmpfs or ramdisk. Not available on Windows. Same as the --mem option.
  • MTR_PARALLEL — If set, defines number of parallel threads executing tests. Same as the --parallel option.
  • MTR_BUILD_THREAD — If set, defines which port number range is used for the server.
  • MTR_PORT_BASE — If set, defines which port number range is used for the server.
  • MTR_NAME_TIMEOUT — Setting of a timeout in minutes or seconds, corresponding to command line option --name-timeout. Available timeout names are TESTCASE, SUITE (both in minutes) and START, SHUTDOWN (both in seconds). These variables are supported from MySQL 5.1.44.
  • MYSQL_TEST — Path name to mariadb-test binary.
  • MYSQLD_BOOTSTRAP — Full path name to mariadbd that has all options enabled.
  • MYSQLTEST_VARDIR — Path name to the var directory that is used for logs, temporary files, and so forth.
  • MYSQL_TEST_DIR — Full path to the mariadb-test directory where tests are being run from.
  • MYSQL_TMP_DIR — Path to temp directory used for temporary files during tests.
Okay so about MTR_PORT_BASE: it was added in MySQL 5.1.45 as a more logical replacement for MTR_BUILD_THREAD. It gives the actual port number directly (will be rounded down to a multiple of 10). If you use MTR_BUILD_THREAD, the port number is found by multiplying this by 10 and adding 10000. Math! 🧮✨

⭐ Tests and the env vars they depend on ⭐

Tests sometimes rely on certain environment variables being defined. For example, certain tests assume that MARIADB-TEST is defined so that mariadb-test can invoke itself with exec $MYSQL_TEST.

Other tests may refer to the last three variables listed in the preceding table, to locate files to read or write. For example, tests that need to create files will typically put them in $MYSQL_TMP_DIR/file_name. 🗃️

💜 Version 1 notes, iykyk 💜

If you're running mariadb-test-run.pl version 1 by setting MTR_VERSION, note that this only affects the test driver, not the test client (and its language) or the tests themselves. Important distinction, don't get it twisted.

A few tests might not run with version 1 because they depend on some feature of version 2. You may have those tests skipped by adding the test name to the file lib/v1/incompatible.tests. This feature is available from MySQL 5.1.40. 🎀

✨ OPTIONS ✨

mariadb-test-run.pl supports literally all the options in the list below, bestie. Also important: an argument of -- tells mariadb-test-run.pl not to process any following arguments as options. That's your "okay we're done with flags now" moment 🫶

  • --help, -h — shows you a help message and dips out. iconic behaviour, no notes 💅
  • --big-test — lets tests marked as "big" actually run. A test gets marked by including the line --source include/big_test.inc, and it will only run if you give this option or if the environment variable BIG_TEST is set to 1. Give this option twice and you'll run only "big" tests 👑

This is typically used for tests that take a very long time to run, or that eat up a ton of resources, so they're just not suitable for running as part of a normal test suite run.

  • --boot-dbx — runs the mariadbd server used for bootstrapping the database through the dbx debugger.
  • --boot-ddd — runs the mariadbd server used for bootstrapping the database through the ddd debugger.
  • --boot-gdb — runs the mariadbd server used for bootstrapping the database through the gdb debugger.
  • --[mtr-]build-thread=number — give it a number and it calculates port numbers from it. The formula is 10 * build_thread + 10000. Instead of a number you can set it to auto, which is also the default value, and in that case mariadb-test-run.pl will allocate a number unique to this host.

The value (number or auto) can also be set with the MTR_BUILD_THREAD environment variable.

The more logical --port-base is supported as an alternative ✨

  • --callgrind — tells valgrind to use callgrind.
  • --check-testcases — checks test cases for side effects. How? By checking system state before and after each test case; if there's any difference at all, a warning to that effect gets written — but the test case will not be marked as failed because of it. This check is enabled by default, so yeah, it's already doing this 💖
  • --client-bindir=path — the path to the directory where the client binaries live.
  • --client-dbx — starts mariadb-test in the dbx debugger.
  • --client-ddd — starts mariadb-test in the ddd debugger.
  • --client-debugger=debugger — starts mariadb-test in the named debugger.
  • --client-gdb — starts mariadb-test in the gdb debugger.
  • --client-libdir=path — the path to the directory where the client libraries live.
  • --combination=value — extra options to pass to mariadbd. The value should be one or more comma-separated mariadbd options. This option is similar to --mariadbd but it should be given two or more times. mariadb-test-run.pl then executes multiple test runs, using the options for each instance of --combination in successive runs. If --combination is given only once, it has no effect (yes, really, one is a no-op, don't come for me 😭). For test runs specific to a given test suite, an alternative to using --combination is to create a combinations file in the suite directory. That file should contain a section of options for each test run.
  • --comment=str — writes str to the output inside lines filled with #, as a form of banner. aesthetic.
  • --compress — compresses all information sent between the client and the server if both support compression.
  • --cursor-protocol — uses the cursor protocol between client and server (implies --ps-protocol).
  • --dbx — starts the mariadbd(s) in the dbx debugger.
  • --ddd — starts the mariadbd(s) in the ddd debugger.
  • --debug — dumps trace output for all clients and servers.
  • --debug-common — same as --debug, but sets the 'd' debug flags to "query,info,error,enter,exit".
  • --debug-server — uses the debug version of the server, but without turning on tracing.
  • --debugger=debugger — starts mariadbd using the named debugger.
  • --debug-sync-timeout=N — controls whether the Debug Sync facility for testing and debugging is enabled. The option value is a timeout in seconds. The default value is 300. A value of 0 disables Debug Sync. The value of this option also becomes the default timeout for individual synchronization points.

mariadb-test-run.pl passes --loose-debug-sync-timeout=N to mariadbd. The --loose prefix is used so that mariadbd doesn't fail if Debug Sync isn't compiled in. thoughtful queen 🧚

  • --defaults-file=file_name — uses the named file as a fixed config file template for all tests.
  • --defaults_extra_file=file_name — adds the settings from the named file to all generated configs.
  • --do-test=prefix|regex — runs all test cases with a name that begins with the given prefix value, or that fulfils the regex. This option is your convenient way to run a whole family of similarly named tests 🎀

The argument for the --do-test option also allows more flexible specification of which tests to perform. If the argument contains a pattern metacharacter other than a lone period, it's interpreted as a Perl regular expression and applies to test names that match the pattern. If the argument contains a lone period or doesn't contain any pattern metacharacters, it's interpreted the same way as previously and matches test names that begin with the argument value. For example, --do-test=testa matches tests that begin with testa, --do-test=main.testa matches tests in the main test suite that begin with testa, and --do-test=main.*testa matches test names that contain main followed by testa with anything in between. In that last case, the pattern match is not anchored to the beginning of the test name, so it also matches names such as xmainytestz. iykyk ✨

  • --dry-run — doesn't run any tests, just prints the list of tests that were selected for execution. a little window-shopping moment 🦋
  • --embedded-server — uses a version of mariadb-test built with the embedded server.
  • --enable-disabled — ignores any disabled.def file, and also runs tests marked as disabled. Success or failure of those tests gets reported the same way as other tests. chaotic but valid 💀
  • --experimental=file_name — specifies a file containing a list of test cases that should be displayed with the [ exp-fail ] code rather than [ fail ] if they fail.

For an example of a file that might be specified via this option, see mariadb-test/collections/default.experimental.

  • --extern option=value — uses an already running server. The option/value pair is what's needed by the mariadb client to connect to the server. Each --extern option can only take one option/value pair as an argument, so you need to repeat --extern for each pair you need. Example:
./mariadb-test-run.pl --extern socket=var/tmp/mariadbd.1.sock alias
Note: if a test case has an .opt file that requires the server to be restarted with specific options, that file will not be used. The test case will likely fail as a result. so like… fair warning bestie 🙈
  • --fast — doesn't perform a controlled shutdown when servers need to be restarted or at the end of the test run. This is equivalent to using --shutdown-timeout=0.
  • --force-restart — always restarts servers between tests.
  • --force — normally mariadb-test-run.pl exits if a test case fails. --force causes execution to continue regardless of test case failure. no quitter energy 💪
  • --gcov — collects coverage information after the test. The result is a gcov file per source and header file.
  • --gcov-src-dir — collects coverage only within the given subdirectory. For example, if you're only developing the SQL layer, it makes sense to use --gcov-src-dir=sql.
  • --gdb — starts the mariadbd(s) in the gdb debugger.
  • --gprof — collects profiling information using the gprof profiling tool.
  • --manual-dbx — uses a server that has already been started by the user in the dbx debugger.
  • --manual-ddd — uses a server that has already been started by the user in the ddd debugger.
  • --manual-debug — uses a server that has already been started by the user in a debugger.
  • --manual-gdb — uses a server that has already been started by the user in the gdb debugger.
  • --manual-lldb — uses a server that has already been started by the user in the lldb debugger.
  • --mark-progress — marks progress with timing (in milliseconds) and line number in var/log/testname.progress. tracking the journey 🎀
  • --max-connections=num — the maximum number of simultaneous server connections that may be used per test. If not set, the maximum is 128. Minimum allowed limit is 8, maximum is 5120. Corresponds to the same option for mariadb-test.
  • --max-save-core=N — limits the number of core files saved, to avoid filling up disks in case of a frequently crashing server. Defaults to 5, set to 0 for no limit. May also be set with the environment variable MTR_MAX_SAVE_CORE.
  • --max-save-datadir=N — limits the number of data directories saved after failed tests, to avoid filling up disks in case of frequent failures. Defaults to 20, set to 0 for no limit. May also be set with the environment variable MTR_MAX_SAVE_DATADIR.
  • --max-test-fail=N — stops execution after the specified number of tests have failed, to avoid using up resources (and time) in case of massive failures. Retries are not counted, and neither are failures of tests marked experimental. Defaults to 10, set to 0 for no limit. May also be set with the environment variable MTR_MAX_TEST_FAIL.
  • --mem — okay so this option is not supported on Windows, noted 📝

It runs the test suite in memory, using tmpfs or ramdisk. This can decrease test times significantly, in particular if you'd otherwise be running over a remote file system. mariadb-test-run.pl attempts to find a suitable location using a built-in list of standard locations for tmpfs and puts the var directory there. This option also affects placement of temporary files, which are created in var/tmp. speed queen behaviour fr fr 🔥

The default list includes /dev/shm. You can also enable this option by setting the environment variable MTR_MEM[=dir_name]. If dir_name is given, it's added to the beginning of the list of locations to search, so it takes precedence over any built-in locations 👑

Once you’ve run tests with --mem inside a mariadb-test directory, a soflink called var will have been set up pointing at the temporary directory — and it gets re-used next time, right up until you delete that soflink. So bestie, you literally don’t have to repeat the --mem option next time. Slay. 💅

  • --mariadbd=value — extra options to pass to mariadbd. The value should be one or more mariadbd options, comma-separated. 🫶
  • --mariadbd-env=VAR=VAL — specify additional environment settings for mariadbd. Want more than one variable set? Just stack more --mariadbd-env options. Easy.
  • --nocheck-testcases — disables the check for test case side effects. Peep --check-testcases for the full description of what that even means.
  • --noreorder — do not reorder tests to reduce the number of restarts; run them in exactly the order given. If a whole suite is to be run, the tests go in alphabetical order, though similar combinations will still get grouped together. If more than one suite is listed, the tests run one suite at a time, in the order listed. No vibes-based shuffling. 🌸
  • --notimer — makes mariadb-test not generate a timing file. The effect? The report from each test case doesn’t include the timing in milliseconds like it normally does. That’s it, that’s the whole thing.
  • --nowarnings — don’t look for and report errors and warnings in the server logs.
  • --parallel={N|auto} — run tests using N parallel threads. By default, 1 thread is used. Use --parallel=auto for auto-setting of N. ✨
  • --[mtr-]port-base=P — specify the base of port numbers to be used; a block of 10 will be allocated. P should be divisible by 10; if it isn’t, it gets rounded down. Running with more than one parallel test thread? Thread 2 uses the next block of 10, and so on down the line.

If the port number is given as auto, which is also the default, mariadb-test-run.pl will allocate a number unique to this host. The value may also be given with the environment variable MTR_PORT_BASE.

If both --build-thread and --port-base are used, --port-base takes precedence. Periodt.

  • --print-testcases — run absolutely nothing, but print details about all tests, in the order they would have been run. Main-character energy of just describing the plans instead of doing them, honestly. 💀
  • --ps-protocol — use the binary protocol between client and server.
  • --record — pass the --record option to mariadb-test. Heads up bestie: this option requires a specific test case to be named on the command line.
  • --reorder — reorder tests to minimize the number of server restarts needed. This is the default behavior. There is no guarantee that a particular set of tests will always end up in the same order, so don’t come for it when it shifts. 🙈
  • --repeat=N — run each test N number of times.
  • --report-features — first run a “test” that reports MariaDB features, displaying the output of SHOW ENGINES and SHOW VARIABLES. This can be used to verify that binaries are built with all required features. Iconic little warm-up act. ⭐
  • --report-times — report how much time has been spent on different phases of test execution.
  • --retry=N — if a test fails, it is retried up to a maximum of N runs (default 1). Retries are also limited by the maximum number of failures before stopping, set with the --retry-failure option. This option has no effect unless --force is also used; without it, test execution will terminate after the first failure.

The --retry and --retry-failure options do not affect how many times a test repeated with --repeat may fail in total, since each repetition is considered a new test case, which may in turn be retried if it fails.

  • --retry-failure=N — when using the --retry option to retry failed tests, stop when N failures have occurred (default 2). Setting it to 0 or 1 effectively turns off retries. 🫠
  • --shutdown-timeout=SECONDS — max number of seconds to wait for servers to do a controlled shutdown before killing them. Default is 10.
  • --skip-combinations — don’t apply combinations; ignore the combinations file or option.
  • --skip-rpl — skip replication test cases.
  • --skip-ssl — don’t start mariadbd with support for SSL connections.
  • --skip-test=regex|regex — specify a regular expression to be applied to test case names. Cases with names that match the expression are skipped — those are the tests to skip.

The argument for the --skip-test option allows more flexible specification of which tests to skip. If the argument contains a pattern metacharacter other than a lone period, it is interpreted as a Perl regular expression and applies to test names that match the pattern. See the description of the --do-test option for the details, iykyk.

  • --skip-test-list=FILE — skip the tests listed in FILE. Each line in the file is an entry and should be formatted as: <TESTNAME> : <COMMENT>
  • --skip-* — any --skip-* options not otherwise recognized by mariadb-test-run.pl are passed to the master server.
  • --sleep=N — pass --sleep=N to mariadb-test. Yeah, it just forwards it. 🦋
  • --sp-protocol — create a stored procedure to execute all queries.
  • --ssl — if mariadb-test-run.pl is started with the --ssl option, it sets up a secure connection for all test cases. In this case, if mariadbd does not support SSL, mariadb-test-run.pl exits with an error message: Couldn't find support for SSL. Not the vibe. 😭
  • --staging-run — run a limited number of tests (no slow tests). Used for running staging trees with valgrind.
  • --start — initialize and start servers with the startup settings for the specified test case. You can use this option to start a server you can connect to later. For example, after building a source distribution you can start a server and connect to it with the mariadb client like this:
shell> cd mariadb-test
shell> ./mariadb-test-run.pl --start alias &
shell> ../mariadb -S ./var/tmp/master.sock -h localhost -u root

If no tests are named on the command line, the server(s) will be started with settings for the first test that would have been run without the --start option.

mariadb-test-run.pl will stop once the server has been started, but will terminate if the server dies. If killed, it will also shut down the server. Ride or die, literally. 💜

  • --start-and-exit — same as --start, but mariadb-test terminates and leaves just the server running.
  • --start-dirty — this is similar to --start, but will skip the database initialization phase and assume that database files are already available. Usually this means you must have run another test first. Trusting the process fr fr.
  • --start-from=test_name — mariadb-test-run.pl sorts the list of names of the test cases to be run, and then begins with test_name.
  • --strace — run the mariadbd executables using strace. Default options are -f -o var/log/'mariadbd-name'.strace.
  • --strace-client — create strace output for mariadb-test, optionally specifying name and path to the trace program to use.

Example: ./mariadb-test-run.pl --strace-client=ktrace

  • --strace-option=ARGS — option to give strace; replaces the default option(s).
  • --stress=ARGS — run a stress test, providing options to mariadb-stress-test.pl. Options are separated by comma.
  • --suite[s]=suite_name... — comma separated list of suite names to run. The default is: main-,archive-,binlog-,csv-,federated-,funcs_1-,funcs_2-,handler-,heap-,innodb-,innodb_fts-,innodb_zip-,maria-,multi_source-,optimizer_unfixed_bugs-,parts-,perfschema-,plugins-,roles-,rpl-,sys_vars-,unit-,vcol-. That’s the whole squad. 👑
  • --stop-file=file — if this file is detected, mariadb-test will not start new tests until the file is removed (also the MTR_STOP_FILE environment variable).
  • --stop-keep-alive=sec — works with --stop-file, printing messages every sec seconds when mariadb-test is waiting to remove the file (for buildbot) (also the MTR_STOP_KEEP_ALIVE environment variable). Little heartbeat so you know it’s still alive. 💓
  • --suite-timeout=minutes — specify the maximum test suite runtime in minutes. The default is 360.
  • --testcase-timeout — specify the maximum test case runtime in minutes. The default is 15.
  • --timediff — used with --timestamp, also prints the time passed since the previous test started.
  • --timer — causes mariadb-test to generate a timing file. The default file is named ./var/log/timer. ⏱️
  • --timestamp — prints a timestamp before the test case name in each test report line, showing when the test ended.
  • --tmpdir=path — the directory where temporary files are stored. The default location is ./var/tmp. The environment variable MYSQL_TMP_DIR will be set to the path for this directory, whether it has the default value or has been set explicitly. This may be referred to in tests.
  • --user=user_name — the MariaDB user name to use when connecting to the server (default root).
  • --user-args — in combination with start* and no test name, drops arguments to mariadbd except those specified with --mariadbd (if any).
  • --valgrind[-all] — run mariadb-test and mariadbd with valgrind. This and the following --valgrind options require that the executables have been built with valgrind support.
  • --valgrind-mariadbd — run the mariadbd server with valgrind.
  • --valgrind-mariadb-test — run the mariadb-test and mariadb-client-test executables with valgrind.
  • --valgrind-option=str — option to give valgrind. Replaces the default option(s). Can be specified more then once. 💅
  • --valgrind-path=path — path to the valgrind executable.
  • --vardir=path — specify the path where files generated during the test run are stored. The default location is ./var. The environment variable MYSQLTEST_VARDIR will be set to the path for this directory, whether it has the default value or has been set explicitly. This may be referred to in tests.
  • --verbose — give more verbose output regarding test execution. Use the option twice to get even more output. Note that the output generated within each test case is not affected.
  • --verbose-restart — write when and why servers are restarted between test cases. Receipts for every restart. 🧾
  • --view-protocol — create a view to execute all non-updating queries.
  • --vs-config=config_val —

Visual Studio configuration used to create executables (default: MTR_VS_CONFIG environment variable). This option is for Windows only.

  • --wait-all — if you're using --start or --start-dirty, this makes mtr wait for all the servers to exit before it terminates. Without it, the whole thing bails the second one (of several) servers gets restarted. 🫶
  • --warnings — after every test, mtr goes snooping through the server log for errors or warnings and reports anything sus; if it finds any, the test gets marked as failed. This is literally the default behavior, and you can turn it off with --nowarnings. 💅

Copyright © 2007, 2010, Oracle and/or its affiliates, 2010-2025 MariaDB Foundation

Okay so legal stuff, but bestie it's important so read it:

This documentation is free software; you can redistribute it and/or modify it only under the terms of the GNU General Public License as published by the Free Software Foundation; version 2 of the License. That's v2 specifically, no swapping it out, periodt.

This documentation is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Like, fr fr, no promises. 😭

You should have received a copy of the GNU General Public License along with the program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA or see http://www.gnu.org/licenses/.

🌈 SEE ALSO 🌈

For more information, please refer to the MariaDB Documentation, available online at https://mariadb.com/docs/ — go click around, it's giving knowledge. 👑

✨ AUTHOR ✨

MariaDB Foundation (http://www.mariadb.org/).

And that's the whole page, bestie! 🦋 You made it, I'm so proud.

That was MariaDB 11.8, dated 5 March 2025 — MARIADB-TEST-RUN(1), signing off. Go run some tests, you absolute icon. 💖🎀🧚

📦 where this page comes from