This works on Linux and on Windows, with rpm/deb/tar.gz/zip
installations.
For rpm/deb it just works, for tar.gz/zip there is no
standard location, so one needs to configure plugin with
-DCMAKE_PREFIX_PATH=/pah/to/mariadb/basedir
after that, `cmake --install .` works too, installing in the same
basedir.
`cmake --build . --target package` works, creating rpm/deb/targz/zip
depending on whether it's Linux or Windows and whether -DRPM or -DDEB
was specified.
* create and install mariadb-plugin-config.cmake
* for now it only supports one plugin per project, error out
if there are many
* deb: move all headers that plugins need to libmariadb-dev,
together with libmysqlservices.a. At least until we'll
create mariadb-plugin-dev. Nobody should need huge
libmariadbd-dev to develop a plugin
* rpm: all in MariaDB-devel already, no changes here
* install wsrep headers too, THD layout depends on WITH_WSREP
* show DBUG_OFF, ENABLED_DEBUG_SYNC, and SAFE_MUTEX to plugins, same
reason (it doesn't happen automatically as they're not in my_config.h)
* but don't install config.h - high chance of name conflict with other
projects and it's an exact copy of my_config.h anyway.
* adjust plugin.cmake to work for external plugins
* move server-internal part of it to top-level CMakeLists.txt
* remove double-defined macros from unireg.h (the guard doesn't help
if unireg.h is included first)
* package plugin metadata as yaml in .tar.gz/.zip
ColumnStore, until fixed, needs a backward-compatibility workaround
Buildbot SRPM builders show it is possible to have dtrace
(the program) installed without the sys/sdt.h.
The dtrace program using -h generated source code that
includes the sys/sdt.h header so lets make sure it exists.
To make sure that SRPM picks up all include headers,
we check that in cmake/build_depends.cmake and let
the discovery of all the include headers contribute
to the build dependencies. Where there is multiple assume
that all header files original from the same package
and search for the last one.
stunnel has been a component used by the rsync SST mechanism of galera
but has never been listed as a package dependency.
Since MDEV-28233 corrected a unencrypted fallback in the the case of
stunnel being absent, we add stunnel as a recommendation for Debian and
RPM packages.
* don't create mariadb-wsrep-new-cluster in the mariadbd-writable path,
the server should not be able to poison the environment with OUTFILE.
Create it in /run
* As in /run it must be deleted by root, let galera_new_cluster delete
it, not the service
* wsrep-start-position cannot be created by root, so avoid a file
for it at all
Assisted-By: Claude:claude-5-opus
* restore result=NULL after free in mysqlshow.c (to prevent double-free)
* remove DBUG_EVALUATE_IF again
* remove useless 'stop slave' from a test
* restore charset encoding in mysqltest.{test,result}
* correct error for unparseable BINLOG data is ER_SYNTAX_ERROR now
* restore old libfmt on rhel-7, gcc 4.8.5 cannot compile anything newer
IF() still evaluates the RHS of an AND condition and this causes
the warning here to be thrown for accsseing deprecated variables,
CMAKE_WARN_DEPRECATED in this case.
Fixed by splitting the IF() into two nested IF()s.
Use modern segmentHeap heap manager on Windows.
The problem it is solving is severily reduced scalability on concurrent
OLTP benchmarks, due to inherent scalability problems in default NT Heap
implementation.
The benchmarks (see the corresponding ticket) show improvements across
the board, with about 5-10% on low concurrency up to several orders of
magnitude on high concurrency.
Also addressed Gemini and Copilot concerns about correct namespace in
the app manifest XML file - make it the same as in Microsoft examples.
scripts/fill_help_tables.sql from
https://github.com/mariadb-corporation/mariadb-docs/ as of
3fb208fcdfed06beb52ef9e305017de2387ff012
Other URL changes are taken from the HTTP redirection URL
from the old KB.
Some test cases where impacted:
* ps_missed_cmds{,_bin_prot} - used a topic_id of 0 that is
now used, used MAX_INT instead.
* range_notembedded used the help data as a test case. As its not
a stable table data, replaces with static data. Test case valid
by ensuring the ANALYZE EXPLAIN and optimizer trace had the same
structure. Also valided the MDEV-24739/MDEV-25069 bug fixes from
where the test case originaled, when reverted, exhibited the
previous behavour before the bug fixes.
remove broken code duplication that
* explicitly listed every submodule that had its own submodules
* blindly executed `${GIT_EXECUTABLE}` after every `(SET GIT_EXECUTABLE)`
mysql-common and MariaDB-common don't install the same files.
mysql-common (in MySQL 8.0) installs character set files
(/usr/share/mysql/charsets/*) and /usr/lib64/mysql (directory only).
MariaDB common installs character set files in /usr/share/mariadb
and the same /usr/lib64/mysql directory along with client plugins
in /usr/lib64/mysql/plugin. The RPM rules of conflict
only will cause troubles on directories if they are installed with
different metatadata (selinux, ownership, permissions) which isn't
the case.
As the character sets are at a different location MariaDB-common
isn't obsoleting mysql-common in a way that provides compatibilty
with mysql-common, for mysql-libs or otherwise, so its just creating
an install conflict.
Users installing perl-DBD-MySQL notice this because its mysql-libs
dependency pulls mysql-common, which conflicts with MariaDB-common.
We correct by removing the conflict and the provides of MariaDB-common
with resepect to mysql-common.
cmake generator expressions are expanded *during the build step*.
If the file is created *during the configuration step* its name
cannot use generator expressions.
BUILD_TYPE=mysql_release changes a bunch of build flags on Linux/UNIX
systems and our CI processes insufficiently test the impacts of these.
This effectively drops the gcc/clang optimization from O3 of a
release down to O2. The performance gains of O3 vs O2 are currently
insufficiently tested (MDEV-19734 is outstanding).
What is clear is amd64v3 is providing the ability of enhanced MMX
instructions which causes segfaults on unaligned addresses
(MDEV-38989 and others). As compilers get smarter and O3 provides
more transforms is safer if the CMAKE_BUILD_TYPE=RelWithDebInfo
experiences of CI have identical compile flags, with BUILD_TYPE=mysql_release
changing to present required features only.
This resolves MDEV-35809 by removing the specialized optimization
for platforms that are unsupported or unmaintained per PR #3744
comments.
When a user sets -DPLUGIN_PARTITION=DYNAMIC or
-DPLUGIN_PERFSCHEMA=DYNAMIC, these plugins are declared
STATIC_ONLY in their CMakeLists.txt. Previously, the
MYSQL_ADD_PLUGIN macro would silently skip building such
plugins: the STATIC branch wouldn't match (because the user
requested DYNAMIC), and the DYNAMIC branch would be blocked
by ARG_STATIC_ONLY. The plugin was simply not built.
This caused confusing downstream compile errors in other
plugins that depended on the missing one:
- PLUGIN_PARTITION=DYNAMIC -> CONNECT fails:
'struct TABLE_SHARE' has no member named
'partition_info_str_len'
'struct TABLE' has no member named 'part_info'
- PLUGIN_PERFSCHEMA=DYNAMIC -> MariaBackup fails:
'MY_WME' was not declared in this scope
'my_read' was not declared in this scope
'MY_FILE_ERROR' was not declared in this scope
- PLUGIN_ARIA=DYNAMIC -> Spider fails:
'MARIA_COLUMNDEF' has not been declared
(Note: Aria is now MANDATORY and already overrides
user input; this was likely reproducible in older
versions where Aria was DEFAULT)
Root cause: The MYSQL_ADD_PLUGIN macro in
cmake/plugin.cmake did not validate that the
user-requested build mode (STATIC or DYNAMIC) was
compatible with the plugin's declared capabilities
(STATIC_ONLY or MODULE_ONLY).
Fix: Add validation immediately after the existing
PLUGIN_xxx value check. If DYNAMIC is requested for a
STATIC_ONLY plugin, or STATIC is requested for a
MODULE_ONLY plugin, emit a FATAL_ERROR with a clear
message telling the user which option to use instead.
Non-MANDATORY plugins with STATIC_ONLY (the new check
catches -DPLUGIN_xxx=DYNAMIC for these):
- partition (sql/CMakeLists.txt)
- perfschema (storage/perfschema/CMakeLists.txt)
- thread_pool_info (sql/CMakeLists.txt)
Conditionally STATIC_ONLY (platform/config-dependent):
- feedback (only on Windows)
The MANDATORY + STATIC_ONLY plugin sql_sequence is
unaffected: the MANDATORY flag overrides user input to
YES before the new check runs.
MODULE_ONLY plugins (the new check catches
-DPLUGIN_xxx=STATIC for these) include all dynamically-
loaded plugins: federated, spider, rocksdb, mroonga,
oqgraph, example, and ~25 others under plugin/ and
storage/.
The YES and AUTO modes are unaffected since they already
gracefully fall through to whichever mode the plugin
supports.
Co-Authored-By: Claude AI <noreply@anthropic.com>
my_large_virtual_alloc(): If large page allocation fails, clear
my_use_large_pages. Outside large page allocation (and IBM AIX),
invoke mmap(2) with PROT_NONE so that no page table entries will
have to be allocated. Also, fix the error reporting.
my_virtual_mem_commit(): Do not set the Linux specific flag MAP_POPULATE
because it would introduce a performance regression on startup.
There is a better, system-wide way to disable the overcommit:
sudo sysctl vm.overcommit_memory=2
HAVE_UNACCESSIBLE_AFTER_MEM_DECOMMIT: Remove. We will always make
the virtual memory unaccessible, so that the operating system
can deallocate the page table entries.
buf_pool_t::create(): Skip the my_virtual_mem_commit() on AIX only.
buf_pool_t::page_guess(): Unconditionally check if the pointer is
within the currently allocated buffer pool.
innodb_buffer_pool_size_max: On 64-bit systems other than IBM AIX,
we will default to 8 TiB.
On 32-bit systems, we retain the default innodb_buffer_pool_size_max=0,
that is, by default, SET GLOBAL innodb_buffer_pool_size=... will be
unable to increase from the initial value.
There is no functional change to the startup logic that adjusts
innodb_buffer_pool_size_max to be at least innodb_buffer_pool_size
rounded up to the extent size (2 MiB on 32-bit, 8 MiB on 64-bit).
Build with vcpkg and WITH_ZLIB=bundled throws error
"Broken installation of vcpkg port zlib" in FIND_PACKAGE(CURL)
Set CMAKE_DISABLE_FIND_PACKAGE_ZLIB to workaround.
Previously, this workaround was hashicorp specific, now we need this also
for videx. Thus setting CMAKE_DISABLE_FIND_PACKAGE_ZLIB was moved to
correct place, inside MYSQL_USE_BUNDLED_ZLIB macro.
apparently a file can be present in *more than one* rpm,
e.g. /usr/bin/dtrace on rhel10 is present *both* in
systemtap-sdt-dtrace and in systemtap-sdt-devel.
Make sure there's a separator between entries.
With PermissionsStartOnly deprecated, remove this from the
systemd service file.
Replace Debian's ExecStartPre "install -d" with a tmpfile
configuration directive creating the directory with this.
Debian's ExecStartPost of the mariadb upgrade uses the !
special executable prefix added in systemd v231 to use
root privs.
After moving the systemd service to using environment files
instead of `systemctl set-environment` in 11.6 (MDEV-19210),
they (wsrep-new-cluster and wsrep-start-position) are located
in /var/lib/mysql along with the socket file in
Fedora/RHEL-based distros. This causes them to have incorrect
selinux permissions and therefore be not readable by systemd.
A solution is to generate these files in the run directory,
instead, which already has correct selinux label mysqld_var_run_t
mysql-selinux-1.0.12. Dissociating these files and the socket
in CMake configs can also prove useful for other things.
This also corrects some of the duplicate code in the build
scripts and made INSTALL_RUNDATADIR into a proper location
and used this for the tmpfiles where the temporary files
are created.
Debian's location is /run/mysqld/ matching its INSTALL_UNIX_ADDRDIR,
which is now a temporary location controlled by tmpfiles.
In 22afd13 Hurd detection was introduced using the processor type,
as incidentally only the hurd-i386 build on Debian was using i686.
This method however does not detect a hurd-amd64 system. Fix this
by using the actual system name following CMake conventions.
Hurd is a kernel project by the GNU project, thus system is called
"GNU".
With PermissionsStartOnly deprecated, remove this from the
systemd service file.
Replace Debian's ExecStartPre "install -d" with a tmpfile
configuration directive creating the directory with this.
Debian's ExecStartPost of the mariadb upgrade uses the !
special executable prefix added in systemd v231 to use
root privs.
After moving the systemd service to using environment files
instead of `systemctl set-environment` in 11.6 (MDEV-19210),
they (wsrep-new-cluster and wsrep-start-position) are located
in /var/lib/mysql along with the socket file in
Fedora/RHEL-based distros. This causes them to have incorrect
selinux permissions and therefore be not readable by systemd.
A solution is to generate these files in the run directory,
instead, which already has correct selinux label mysqld_var_run_t
mysql-selinux-1.0.12. Dissociating these files and the socket
in CMake configs can also prove useful for other things.
This also corrects some of the duplicate code in the build
scripts and made INSTALL_RUNDATADIR into a proper location
and used this for the tmpfiles where the temporary files
are created.
Debian's location is /run/mysqld/ matching its INSTALL_UNIX_ADDRDIR,
which is now a temporary location controlled by tmpfiles.
Don't exclude OpenSSL runtime dependencies, even if they are in
Windows system directory. chocolatey package manager, and underlying
ShiningLight installer and manager puts them there.
Previously, the assumption was that system32 only contains OS libraries.
That is normally also the case, except this specific case.
mysql-selinux-1.0.14 provides the necessary labels for
MariaDB to function correctly.
Thanks Pavol Sloboda for the bug forwarding and a ready to
package solution.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2395701
