This formats and sorts the files the same way they are in the official
Debian packaging, making it easier to compare the files in Debian vs
upstream using commands such as `git difftool --dir-diff main --
debian`. Comparing the contents at least once a year is important in
ensuring all packaging improvements get their way into both Debian
official and upstream Debian packaging.
See https://salsa.debian.org/mariadb-team/mariadb-server/-/tree/debian/latest/debian
The formatting done by `debputy reformat --style black` is basically the
same as running `wrap-and-sort -vast`.
There are no functional changes, this is a pure formatting change.
This is intentionally done on the `main` branch in MariaDB. The stable
release branches are unlikely to ever get any changes in the
`debian/control` file, and thus formatting or maintaining it is
irrelevant. The merges from stable releases to latest `main` should not
bring any `debian/control` file changes, as adding or removing
dependencies, changing Debian compat levels or other changes are
invasive and shouldn't be done in stable releases at all.
VIDEX is a Disaggregated and Extensible Virtual Index Engine designed
to perform efficient and accurate what-if analysis for tasks such as
index recommendation.
Fix template linking error for gcc
debian: Add packaging for the VIDEX plugin
This commit adds the necessary files to build `mariadb-plugin-videx` as a separate Debian package.
- Add `COMPONENT videx-engine` to CMakeLists.txt to register the plugin.
- Define the `mariadb-plugin-videx` package in debian/control.
- Create `debian/mariadb-plugin-videx.install` to include the plugin .so and .cnf files.
debian: fix indent in debian/control
fix bugs from empty table
videx: fix RPM autobake by adding CPACK summary/description
Instead of `NULL`ifying of this member a finer approach is taken to
screen the replicated temporary tables from the slave applier
when it runs within `start_new_trans` context.
For that *all* access critical `THD::{has,lock,unlock}_temporary_tables`
functions are made to check possible `start_new_trans` condition.
This measure forces `start_new_trans` executing slave thread to always take
the normal thread access path to a temporary table repository.
This commit also unifies with sql/temporary_tables.cc checking of the
current thread is slave with usage of THD::rgi_slave instead of
THD::slave_thread (last time chosen by MDEV-33426).
Tested with rpl.create_or_replace_mix2 of GTT feature branch.
The script is likely misleading to users stating 'SUCCESS' about things
it didn't do anything about, leading to false sense of security. Improve
the output to be more clear about what it is doing or is not doing.
Introduces `FLUSH HASHICORP_KEY_MANAGEMENT_CACHE` command to flush the
cached keys in the HashiCorp Key Management plugin, enabling rotation of
encryption keys without needing to restart the server.
The new `INFORMATION_SCHEMA.HASHICORP_KEY_MANAGEMENT_CACHE` table lists
the key id and key version from the latest version cache. The table's
content can be viewed using `SHOW HASHICORP_KEY_MANAGEMENT_CACHE` or
queried directly.
Executing the `FLUSH` command requires `RELOAD` privilege and access to
INFORMATION_SCHEMA table requires `PROCESS` privilege.
Bugfix (squashed):
MDEV-38111: SIGSEGV when multiple servers use the same Vault KV storage for encrypted tables
Problem:
A data race between InnoDB background threads reading the cached keys
and the thread executing FLUSH command clearing it without acquiring
a lock. This non-synchronized memory write caused InnoDB threads that
were concurrently reading the cache to access freed memory, leading to
a crash.
Fix:
Acquire the lock before clearing the latest version cahce. This
ensures the cache clearing operation is serialized, preventing
concurrent access and resolving the data race.
This is a combined patch of various spelling fixes originally done in
Debian.
* Fix misc typos in MariaDB Server
* Fix spelling of 'allows one to'
Fix the following Lintian nags introduced in commit
c8d040938a:
I: mariadb-backup: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-backup]
I: mariadb-server-core: spelling-error-in-binary "allows to" "allows one to" [usr/sbin/mariadbd]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-client-test-embedded]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/mariadb-test-embedded]
I: mariadb-test: spelling-error-in-binary "allows to" "allows one to" [usr/bin/test-connect-t]
We extend from the SQL standard to match the functionality of other
databases that allow the inclusion of a CTE definition prior to update
and delete statements.
These CTEs are currently read only, like other derived tables, so
cannot have their columns updated in updates set clause, nor have rows
removed in the delete statement.
Approved by: Oleksandr Byelkin (sanja@mariadb.com)
Move classes Json_string, and Json_saved_parser_state from
opt_histogram_json.cc to the newly created file sql_json_lib.h
Additionally, make the function json_unescape_to_string public earlier
defined as static in opt_histogram_json.cc, by
adding the declaration in sql_json_lib.h
Needed this change so that, the classes and functions can be reused in
other pieces of the code.
Analysis:
json_valid() does not call any function recursively so insertion in the
table works ok. Since the depth of json is 5000, json_normalize()
recursively calls json_normalize_sort(), json_norm_to_string() and
json_norm_value_free() and we hit the stack limit.
Fix:
Get rid of the recursive nature of the functions and make them iterative.
This way we will never hit stack limit for bigger depths.
a fix for MDEV-15990 has unintentionally added
HA_EXTRA_REMEMBER_POS/HA_EXTRA_RESTORE_POS on the code path for normal,
not versioned, deletes.
Let's restore the old logic.
followup for 8001679af6
We need to ensure that all the unions are marked as UNCACHEABLE_RAND in
cases like:
select * from t1 where 1 in (select 1 union select 2 union select RAND());
table->pos_in_table_list is problematic, it can become
dangled when an SP is reparsed. Let's avoid it and directly
prefer TABLEs where a sequence is ready for inserts.
followup for 516f68af9e
table->pos_in_table_list is problematic, it can become
dangled when an SP is reparsed. Let's avoid it and directly
prefer TABLEs where a sequence is ready for inserts.
followup for 516f68af9e
MDEV-37726 moved wsrep-start-position to INSTALL_RUNDATADIR
and made the latter to be created by systemd-tmpfiles.
Now postin scriptlet has to run systemd-tmpfiles explicitly
to make sure INSTALL_RUNDATADIR exists before restarting
the server.
followup for 649216e70d
* remove the file to be --repeat friendly
* specify the correct defaults-group-suffix. Spider doesn't use the
conventional .1 group, so MYSQLD_CMD skips a lot of config options,
in particular it doesn't read --tmpdir and creates files in /tmp
(Variant 2)
SEL_TREE* tree_or(SEL_TREE *X, SEL_TREE *Y) tries to conserve memory by
reusing object *X for the return value when possible.
MDEV-34620 has added logic to disable construction of index_merge plans
for N-way ORs with large N. That logic interfered with object reuse logic:
for the parameters of:
X = SEL_TREE{ trees=[key1_treeA, key2_treeB]}
Y = SEL_TREE{ trees=[key1_treeC]}
we would decide to reuse object X.
For key1, we would produce key_or(key1_treeA, key1_treeC)
but key2_treeB would be just left there.
Then, we would construct a range scan from key2_treeB.
Fixed by moving the "disable building index_merge plans" logic into a
location where it would not interfere with object reuse logic.
The NULL-aware index statistics fix is now controlled by the
FIX_INDEX_STATS_FOR_ALL_NULLS flag and disabled by default
for preserving execution plan stability in stable versions.
To enable:
SET @@new_mode = 'FIX_INDEX_STATS_FOR_ALL_NULLS';
Or via command line:
--new-mode=FIX_INDEX_STATS_FOR_ALL_NULLS
Or in configuration file:
[mysqld]
new_mode=FIX_INDEX_STATS_FOR_ALL_NULLS
`all_nulls_key_parts` bitmap is now calculated at set_statistics_for_table()
it was only truly used in one place, where it needed to compare
its arguments before removing an entry from the cache. in the second
place it was used, the comparison was redundant, it was only
called to remove, not to compare.
let's replace it with a function that just removes.
