At lower_case_table_names=2 this returns nothing.
CREATE DATABASE Db1;
CREATE FUNCTION Db1.f1(a INT) RETURNS INT RETURN a;
SELECT ROUTINE_NAME FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA='Db1';
mysql.proc records the function's database as db1, in lower case.
Creating a routine lower-cases its database name whenever
lower_case_table_names is anything but 0, at sql/sp_head.h:121. The
datadir, SCHEMATA and DATABASE() all keep Db1.
CALL Db1.f1() still works, because calling a routine lower-cases the
database name too and then searches mysql.proc for db1. The query
above never lower-cases it. It searches for Db1, and mysql.proc.db
collates utf8mb3_bin, so the comparison runs byte for byte and no row
matches.
At setting 1 the server lower-cases the filter value as well, at
sql/sql_show.cc:4394, and lower-cases every name it stores, so the
query and the table always agree. Setting 2 lower-cases the routine's
copy and nothing else.
The fix lower-cases the filter value before the search.
Sorting the same query brings the row back.
SELECT ROUTINE_NAME FROM information_schema.ROUTINES
WHERE ROUTINE_SCHEMA='Db1' ORDER BY ROUTINE_NAME;
The sort keeps the filter from reaching that search. The server reads
all of mysql.proc instead, then applies the WHERE to ROUTINE_SCHEMA,
which compares case insensitively. That shape answered correctly all
along.
The same search fills PARAMETERS and backs SHOW FUNCTION STATUS, SHOW
PROCEDURE STATUS, SHOW PACKAGE STATUS and SHOW PACKAGE BODY STATUS.
Every one returned nothing for Db1. mariadb-dump lists routines with
SHOW FUNCTION STATUS WHERE Db=..., at client/mysqldump.cc:2859, which
is the main.mysqldump failure.
Setting 0 keeps Db1 and db1 as two databases holding two routines. A
case sensitive volume confirms both stay distinct before and after this
change. beb9a5459d (MDEV-20609) added the search in 10.11.1.
main.lowercase_routines runs both query shapes.
11.8 fix for I_S.TABLES.INDEX_LENGTH column
Take into account both data_file_length and index_file_length,
they both take space and both belong to the vercor index.
CREATE SERVER used to:
* support arbitrary options in backticks and not in backticks
* hard-coded historical options worked *only* without backticks
* PORT range was different when given as a number or a string
all that is fixed, unused keywords are removed
The "is it my own thread" check compared the login user name
(Security_context::user) and ignored the host, so u1@localhost could see
and kill threads of u1@'127.0.0.1'.
Compare the authenticated account instead:
* all comparisons are done in sctx->is_priv_user() now
* change user_matches() to priv_user_matches(), which uses is_priv_user()
* use it in KILL, KILL USER, SHOW PROCESSLIST, I_S.PROCESSLIST,
COM_PROCESS_INFO and SHOW EXPLAIN/ANALYZE FOR.
* all the remaining places use is_priv_user() directly instead
of doing strcmp: SHOW GRANTS, SHOW CREATE PROCEDURE, I_S.VIEWS,
the DEFINER clause, optimizer trace and change_security_context().
Assisted-by: Claude:claude-5-opus
Store all READ_ONLY sysvar values in the read_only_root
Even though READ_ONLY sysvars are protected, for string variables
it usually means that the pointer cannot be changed. The value it
points to - the string itself - still can be. Let's store all
values of string READ_ONLY sysvars in the read_only_root.
sysvars that point directly into argv are copied to read_only_root.
sysvars that have their values calculated and allocated now
must be explicitly marked with PREALLOCATED to let it know they
have to be free()-d.
Assisted-By: Claude:claude-4.8-opus
Protect all READ_ONLY sysvars from run-time changes.
Put them into a separate section and use my_virtual_mem_protect()
to make this section read-only before the server starts accepting
connections.
Verify that they're all protected in the sys_var constructor.
One exception: opt_noacl (--skip-grant-tables) can be changed
from 1 to 0 on FLUSH PRIVILEGES. Let's briefly drop the
protection for this 1->0 change. It can be needed only once
in a server lifetime and only if it was started with --skip-grant-tables
On shutdown the protection is removed, making variables writable
again because shutdown resets some of them during the cleanup
Assisted-By: Claude:claude-4.8-opus
WITH GRANT OPTION is not a privilege in the standard sense,
so whenever INFORMATION_SCHEMA visibility dictates "any privilege"
this does not include WITH GRANT OPTION, even though GRANT_ACL
is a privilege in MariaDB.
Assisted-By: Claude:claude-4.6-sonnet
1.
Only allow #mysql50# prefix on table names that
can not be decoded from a file name to a table name.
It is an error to put this prefix on a name that can be accessed
as a valid table name without a prefix. Use `t1` not `#mysql50#t1`,
use `a-b` not `#mysql50#a@002db`.
2.
Don't allow creation of new tables with the #mysql50# prefix.
Except when in SQLCOM_ALTER_DB_UPGRADE - main.upgrade test runs
ALTER DATABASE `#mysql50#mysqltest-1` UPGRADE DATA DIRECTORY NAME;
This command moves tables from the old db name to the new db name,
and some of these tables also have old #mysql50# names.
3.
Also don't allow to create such databases, views, partitions,
subpartitions, sequences, triggers.
Three problems:
1. Option value specified as `foo bar` was not quoted,
printed as foo bar, breaking CREATE TABLE.
2. Option value that included */ was printed as is, in unknown
options when the whole option was commented out, this broke the
comment: /* opt='val*/ue' */
3. Option names can include */ too, `opt*/ion`=1
Fix: simplify value printing, ignore the original quoting, always
print the value quoted as a string. Break comment markers with an
escape (as *\/) if inside a comment. As \-escapes don't work inside,
backticks, we cannot use `-quoting for option values at all.
For the same reason we cannot allow */ inside option names, thus
let's only allow keywords for option names and reject fancy names
even if IGNORE_BAD_TABLE_OPTIONS is in force.
gcc 15.1.15 gives the following error, possible from static struct
initialization:
/my/maria-11.8/sql/sql_show.cc: In function ‘void __static_initialization_and_destruction_0()’:
/my/maria-11.8/sql/sql_show.cc:11356:1: error: the frame size of 62880 bytes is larger than 16384 bytes [-Werror=frame-larger-than=]
Fixed by adding PRAGMA_DISABLE_CHECK_STACK_FRAME to sql_show.cc
Vector indexes are stored in a separate internal table (hlindex).
The main table's storage engine knows nothing about it, INDEX_LENGTH
was always reported as 0 for tables with vector indexes.
the fix: after calling info() on the main table handler in sql_show.cc,
check if the table has an hlindex, open it if needed, and add its data_file_length to
index_file_length before writing to the information schema record.
Problem:
UBSAN reports runtime errors in string comparision functions when
pointer arithmetic is done without checking NULL.
Fix:
- Add debug asserts in `strnncoll` function to catch NULL pointers.
- Define a new function `streq_safe` as a replacement for `streq`,
capable of handling NULL pointers. Replace `streq` with `streq_safe`
at multiple call sites, identified by the debug asserts.
- Add empty identifier checks in `is_infoschema_db` and
`is_perfschema_db` before calling the deep character-set based
comparision.
gcc 15.1.15 gives the following error, possible from static struct
initialization:
/my/maria-11.8/sql/sql_show.cc: In function ‘void __static_initialization_and_destruction_0()’:
/my/maria-11.8/sql/sql_show.cc:11356:1: error: the frame size of 62880 bytes is larger than 16384 bytes [-Werror=frame-larger-than=]
Fixed by adding PRAGMA_DISABLE_CHECK_STACK_FRAME to sql_show.cc
paritioning has its own method for printing engine options,
it wasn't consistent with how table options were printed - didn't
use quotes, ignored sql_mode, so wasn't future and dump/import safe.
let's get rid of it and use the same method that prints per-table
engine options.
let's simplify the code by removing copying of part_elem->connect_string
to table->s->connect_string. Move CONNECTION support from he server into
engines, engines define TOPTION("CONNECTION") if they want to support it,
it's stored in the option_struct and handled by the option_struct fix.
Problems:
* Mroonga used CONNECTION for something but there were no tests for it.
Removed Mroonga support for CONNECTION as requested by the maintainer
in MDEV-38530
* DROP/ALTER SERVER command used to close all tables using the server
in question, avoiding the need for FLUSH TABLES. This functionality
never worked for partitioned tables anyway and is now removed. Will be
done properly in MDEV-37827.
some I_S tables require "any non-SELECT privilege on the table".
If only SELECT was granted on the global level and something non-SELECT
on the schema level, then we need to check schema level privileges
explicitly, because check_grant() doesn't do that and get_all_tables()
doesn't look deeper if SELECT is present on the global level.
According to SQL standard, rows from `INFORMATION_SCHEMA.TRIGGERS` table
should be visible to users with non-SELECT privileges on the columns.
`ACTION_CONDITION`, `ACTION_STATEMENT` and `DEFINER` columns should be
visible only if the user is the owner of the schema.
MariaDB uses `TRIGGER` privilege instead of owner, which controls the
visibilty of all columns, including those which only need non-SELECT
privileges.
This fix
- Allows users with non-SELECT privileges- INSERT, DELETE or UPDATE,
to see rows in `INFORMATION_SCHEMA.TRIGGERS` table.
- Ensure `ACTION_CONDITION`, `ACTION_STATEMENT` and `DEFINER` columns
are `NULL` unless the user is the owner of the schema or has `TRIGGER`
privilege.
Setting a name for the the THD::security_ctx:user field for wsrep applier threads.
With this, the audit log events related to wsrep applying will be written in the
audit log.
Using user name <wsrep_applier> for wsrep appliers. This is for having identical
look with async replication, which uses: <replication_slave> for audit logging.
Using same approach as async replication to replace the security_ctx user name
with "system user" for processlist output.
Commit has also a mtr test galera.MDEV-35511, to verify wsrep applier audit logging.
The test does not install/uninstall audit log plugin, but loads the audit log plugin
before the test. This is because uninstalling the audit log plugin gives a warning
saying that plugin is busy and uninstall will be delayed until server shutdown.
This anomaly must be because of the applier thread being active audit logger.
Same problem with plugin uninstall happens also with async relication workers.
If plugn would remain installed, the post test sanity check complains of mismatching
state of pre and post test states, and test execution would fail for this.
