Default Role Implementation #1

cvicentiu · 2014-06-06T20:48:39Z

No description provided.

Removed unused variable. Fixed long (>80 lines)

vuvova · 2014-06-13T19:31:52Z

sql/share/errmsg-utf8.txt

@@ -2932,6 +2932,9 @@ ER_HOST_NOT_PRIVILEGED
        spa "Servidor '%-.64s' no está permitido para conectar con este servidor MariaDB"
        swe "Denna dator, '%-.64s', har inte privileger att använda denna MariaDB server"
        ukr "Хосту '%-.64s' не доволено зв'язуватись з цим сервером MariaDB"
+ER_DEFAULT_ROLE_ANONYMOUS_USER


This (and below) is wrong, you cannot add error messages in the middle of the file, because it'll shift other error messages down, and error message numbers should never change. Always add new errors at the end, under ER_SLAVE_SKIP_NOT_IN_GTID

Right, I'll fix this. I kind of thought that was not the right way to do it.

vuvova · 2014-06-13T22:17:06Z

Ok, I've added my comments in the diff. Overall that was very good! Only a few changes needed, then I'll merge. Thanks!

Also fixed wording on one message.

cvicentiu · 2014-07-20T00:28:43Z

Sorry for the late follow up!

I've addressed all the comments. I've rebased the whole work on top of the master branch to allow for automatic merging.

There were a couple of issued I discovered, such as:
set default role current_role for current_user;
This was not accepted by the parser. Now it is fixed. I've also split the test into a couple more unit tests. I'm also testing a lot more of the functionality.

Added extra check for default_role column.

vuvova · 2014-07-22T15:45:15Z

thanks. I'll take it from here and merge it now.

The test case makes use of the fine DEBUG_SYNC facility. Furthermore, since it needs synchronization on internal threads (dump and SQL threads) the server code has DEBUG_SYNC commands internally deployed and activated through the DBUG_EXECUTE_IF macro. The internal DBUG_SYNC commands are then controlled from the test case through the DEBUG variable. There were three problems around the DEBUG + DEBUG_SYNC facility usage: 1. When signaling the SQL thread to continue, the test would reset immediately the DEBUG_SYNC variable. This could mean that the SQL thread might loose the signal and continue to wait forever; 2. A similar scenario was happening with the dump thread on the master. This thread was instructed to wait, and later it would be signaled to continue, but immediately after the DEBUG_SYNC would be reset. This could lead to the dump thread missing the signal and wait forever; 3. The test was not cleaning itself up with respect to the instrumentation of the dump thread. This would leave the conditional execution of an internal DEBUG_SYNC command active (through the usage of DBUG_EXECUTE_IF). We fix #1 and #2 by waiting for the threads to receive the signal and only then issue the reset. We fix #3 by reseting the DEBUG variable, thus deactivating the dump thread internal DEBUG_SYNC command.

Removed unused variable. Fixed long (>80 lines)

The test case makes use of the fine DEBUG_SYNC facility. Furthermore, since it needs synchronization on internal threads (dump and SQL threads) the server code has DEBUG_SYNC commands internally deployed and activated through the DBUG_EXECUTE_IF macro. The internal DBUG_SYNC commands are then controlled from the test case through the DEBUG variable. There were three problems around the DEBUG + DEBUG_SYNC facility usage: 1. When signaling the SQL thread to continue, the test would reset immediately the DEBUG_SYNC variable. This could mean that the SQL thread might loose the signal and continue to wait forever; 2. A similar scenario was happening with the dump thread on the master. This thread was instructed to wait, and later it would be signaled to continue, but immediately after the DEBUG_SYNC would be reset. This could lead to the dump thread missing the signal and wait forever; 3. The test was not cleaning itself up with respect to the instrumentation of the dump thread. This would leave the conditional execution of an internal DEBUG_SYNC command active (through the usage of DBUG_EXECUTE_IF). We fix #1 and #2 by waiting for the threads to receive the signal and only then issue the reset. We fix #3 by reseting the DEBUG variable, thus deactivating the dump thread internal DEBUG_SYNC command.

Added mandatory thd parameter to Item (and all derivative classes) constructor. Added thd parameter to all routines that may create items. Also removed "current_thd" from Item::Item. This reduced number of pthread_getspecific() calls from 290 to 177 per OLTP RO transaction.

1. Fixing Field_time::get_equal_const_item() to pass TIME_FUZZY_DATES and TIME_INVALID_DATES to get_time_with_conversion(). This is needed to make the recursively called Item::get_date() return non-NULL values on garbage input. This makes Field_time::get_equal_const_item() work consistently with how Item::val_time_packed() works. 2. Fixing Item::get_date() to return TIME'00:00:00' rather than DATE'0000-00-00' on empty or garbage input when: - TIME_FUZZY_DATES is enabled - The caller requested a TIME value (by passing TIME_TIME_ONLY). This is needed to avoid conversion of DATE'0000-00-00' to TIME in get_time_with_conversion(), which would erroneously try to subtract CURRENT_DATE from DATE'0000-00-00' and return TIME'-838:59:59' rather than the desired zero value TIME'00:00:00'. #1 and #2 fix these type of scripts to return one row with both MyISAM and InnoDB, with and without an index on t1.b: CREATE TABLE t1 (a ENUM('a'), b TIME, c INT, KEY(b)); INSERT INTO t1 VALUES ('','00:00:00',0); SELECT * FROM t1 WHERE b=''; SELECT * FROM t1 WHERE a=b; SELECT * FROM t1 IGNORE INDEX(b) WHERE b=''; SELECT * FROM t1 IGNORE INDEX(b) WHERE a=b; Additionally, #1 and #2 fix the originally reported in MDEV-9604 crash in Item::save_in_field(), because now execution goes through a different path, so save_in_field() is called for a Item_time_literal instance (which is non-NULL) rather than a Item_cache_str instance (which could return NULL without setting null_value). 3. Fixing Field_temporal::get_equal_const_item_datetime() to enable equal field propagation for DATETIME and TIMESTAMP in case of comparison (e.g. when ANY_SUBST), for symmetry with Field_newdate::get_equal_const_item(). This fixes a number of problems with empty set returned on comparison to empty/garbage input. Now all SELECT queries in this script return one row for MyISAM and InnoDB, with and without an index on t1.b: CREATE TABLE t1 (a ENUM('a'), b DATETIME, c INT, KEY(b)); INSERT INTO t1 VALUES ('','0000-00-00 00:00:00',0); SELECT * FROM t1 WHERE b=''; SELECT * FROM t1 WHERE a=b; SELECT * FROM t1 IGNORE INDEX(b) WHERE b=''; SELECT * FROM t1 IGNORE INDEX(b) WHERE a=b;

Leave the code in, but #ifdef it away to avoid compilation error

Fix the comment to describe the sequence of events correctly

…dex condition (Based on the original patch by Jason Cu) Part #1: - Add ha_handler_stats::{icp_attempts,icp_match}, make handler_index_cond_check() increment them. - ANALYZE FORMAT=JSON now prints r_icp_filtered based on these counters.

(Based on the original patch by Jason Cu) Part #1: - Add ha_handler_stats::{icp_attempts,icp_match}, make handler_index_cond_check() increment them. - ANALYZE FORMAT=JSON now prints r_icp_filtered based on these counters.

(Based on original patch by Oleksandr Byelkin) Multi-table DELETE can execute via "buffered" mode: at phase #1 it collects rowids of rows to be deleted, then at phase #2 in multi_delete::do_deletes() it calls handler->rnd_pos() to read rows to be deleted and deletes them. The problem occurred when phase #1 used Rowid Filter on the table that phase #2 would be deleting from. In InnoDB, h->rnd_init(scan=false) and h->rnd_pos() is an index scan over PK under the hood. So, at phase #2 ha_innobase::rnd_init() would try to use the rowid filter an assertion inside ha_innobase::rnd_init(). Note that multi-table UPDATE works similarly but was not affected, because patch for MDEV-7487 added code to disable rowid filter for phase #2 in multi_update::do_updates(). This patch changes the approach: - It makes InnoDB not use Rowid Filter in rnd_pos() scans: it is disabled in ha_innobase::rnd_init() and enabled back in ha_innobase::rnd_end(). - multi_update::do_updates() no longer disables rowid filter for phase#2 as it is no longer necessary.

(Based on original patch by Oleksandr Byelkin) Multi-table DELETE can execute via "buffered" mode: at phase #1 it collects rowids of rows to be deleted, then at phase #2 in multi_delete::do_deletes() it calls handler->rnd_pos() to read rows to be deleted and deletes them. The problem occurred when phase #1 used Rowid Filter on the table that phase #2 would be deleting from. In InnoDB, h->rnd_init(scan=false) and h->rnd_pos() is an index scan over PK under the hood. So, at phase #2 ha_innobase::rnd_init() would try to use the Rowid Filter and hit an assertion inside ha_innobase::rnd_init(). Note that multi-table UPDATE works similarly but was not affected, because patch for MDEV-7487 added code to disable rowid filter for phase #2 in multi_update::do_updates(). This patch changes the approach: - It makes InnoDB not use Rowid Filter in rnd_pos() scans: it is disabled in ha_innobase::rnd_init() and enabled back in ha_innobase::rnd_end(). - multi_update::do_updates() no longer disables Rowid Filter for phase#2 as it is no longer necessary.

Fixing applying the COLLATE clause to a parameter caused an error error: COLLATION '...' is not valid for CHARACTER SET 'binary' Fix: - Changing the collation derivation for a non-prepared Item_param to DERIVATION_IGNORABLE. - Allowing to apply any COLLATE clause to expressions with DERIVATION_IGNORABLE. This includes: 1. A non-prepared Item_param 2. An explicit NULL 3. Expressions derived from #1 and #2 For example: SELECT ? COLLATE utf8mb_unicode_ci; SELECT NULL COLLATE utf8mb_unicode_ci; SELECT CONCAT(?) COLLATE utf8mb_unicode_ci; SELECT CONCAT(NULL) COLLATE utf8mb_unicode_ci - Additional change: removing the multiplication to mbmaxlen from the fix_char_length_ulonglong() argument, because the multiplication already happens inside fix_char_length_ulonglong(). This fixes a too large column size created for a COLLATE clause.

Fixing applying the COLLATE clause to a parameter caused an error error: COLLATION '...' is not valid for CHARACTER SET 'binary' Fix: - Changing the collation derivation for a non-prepared Item_param to DERIVATION_IGNORABLE. - Allowing to apply any COLLATE clause to expressions with DERIVATION_IGNORABLE. This includes: 1. A non-prepared Item_param 2. An explicit NULL 3. Expressions derived from #1 and #2 For example: SELECT ? COLLATE utf8mb_unicode_ci; SELECT NULL COLLATE utf8mb_unicode_ci; SELECT CONCAT(?) COLLATE utf8mb_unicode_ci; SELECT CONCAT(NULL) COLLATE utf8mb_unicode_ci - Additional change: preserving the collation of an expression when the expression gets assigned to a PS parameter and evaluates to SQL NULL. Before this change, the collation of the parameter was erroneously set to &my_charset_binary. - Additional change: removing the multiplication to mbmaxlen from the fix_char_length_ulonglong() argument, because the multiplication already happens inside fix_char_length_ulonglong(). This fixes a too large column size created for a COLLATE clause.

…IMIT Part #1: hook into the join optimizer. The choice between index-based access methods is not implemented yet.

here MSAN complains that ==218853==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f84a77c60a3 in _gnutls_rnd_init /tmp/msan/lib/random.c:69:6 #1 0x7f84a77c60a3 in gnutls_rnd /tmp/msan/lib/random.c:168:6 but the line lib/random.c:69 in gnutls-3.7.1 is 69 if (unlikely(!rnd_initialized)) { and rnd_initialized is declared as 40 static _Thread_local unsigned rnd_initialized = 0; which apparently MSAN isn't happy with

…IMIT Part #1: hook into the join optimizer. The choice between index-based access methods is not implemented yet.

Changing the return type of the following functions: - CURRENT_TIMESTAMP, CURRENT_TIMESTAMP(), NOW() - SYSDATE() - FROM_UNIXTIME() from DATETIME to TIMESTAMP. Note, the old function NOW() returning DATETIME is still available as LOCALTIMESTAMP or LOCALTIMESTAMP(), e.g.: SELECT LOCALTIMESTAMP, -- DATETIME CURRENT_TIMESTAMP; -- TIMESTAMP The change in the functions return data type fixes some problems that occurred near a DST change: - Problem #1 INSERT INTO t1 (timestamp_field) VALUES (CURRENT_TIMESTAMP); INSERT INTO t1 (timestamp_field) VALUES (COALESCE(CURRENT_TIMESTAMP)); could result into two different values inserted. - Problem #2 INSERT INTO t1 (timestamp_field) VALUES (FROM_UNIXTIME(1288477526)); INSERT INTO t1 (timestamp_field) VALUES (FROM_UNIXTIME(1288477526+3600)); could result into two equal TIMESTAMP values near a DST change. Additional changes: - FROM_UNIXTIME(0) now returns SQL NULL instead of '1970-01-01 00:00:00' (assuming time_zone='+00:00') - UNIX_TIMESTAMP('1970-01-01 00:00:00') now returns SQL NULL instead of 0 (assuming time_zone='+00:00' These additional changes are needed for consistency with TIMESTAMP fields, which cannot store '1970-01-01 00:00:00 +00:00'.

Changing the return type of the following functions: - CURRENT_TIMESTAMP, CURRENT_TIMESTAMP(), NOW() - SYSDATE() - FROM_UNIXTIME() from DATETIME to TIMESTAMP. Note, the old function NOW() returning DATETIME is still available as LOCALTIMESTAMP or LOCALTIMESTAMP(), e.g.: SELECT LOCALTIMESTAMP, -- DATETIME CURRENT_TIMESTAMP; -- TIMESTAMP The change in the functions return data type fixes some problems that occurred near a DST change: - Problem #1 INSERT INTO t1 (timestamp_field) VALUES (CURRENT_TIMESTAMP); INSERT INTO t1 (timestamp_field) VALUES (COALESCE(CURRENT_TIMESTAMP)); could result into two different values inserted. - Problem #2 INSERT INTO t1 (timestamp_field) VALUES (FROM_UNIXTIME(1288477526)); INSERT INTO t1 (timestamp_field) VALUES (FROM_UNIXTIME(1288477526+3600)); could result into two equal TIMESTAMP values near a DST change. Additional changes: - FROM_UNIXTIME(0) now returns SQL NULL instead of '1970-01-01 00:00:00' (assuming time_zone='+00:00') - UNIX_TIMESTAMP('1970-01-01 00:00:00') now returns SQL NULL instead of 0 (assuming time_zone='+00:00' These additional changes are needed for consistency with TIMESTAMP fields, which cannot store '1970-01-01 00:00:00 +00:00'

There seem to be 2 ASAN issues using mysqltest.cc (at least using test binlog.binlog_autocommit_off_no_hang): 1. (Fixed by this test) cur_con is not NULLed when freeing connections. At backtrace time, it can be read (though the backtrace is likely caused by point 2). 2. (Still to be fixed) There is a leak in mariadb_lib.c line 3863: ``` OPT_SET_EXTENDED_VALUE(&mysql->options, tls_verification_callback, arg1); ``` with stack ================================================================= ==288928==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1568 byte(s) in 4 object(s) allocated from: #0 0x5ceaa4ebad7d in calloc (./server/build116_asan/client/mariadb-test+0x1dcd7d) (BuildId: 21b3097a37beada873a1eaa15c1ea1f16d3ad6d7) #1 0x5ceaa4f6457f in mysql_optionsv ./server/libmariadb/libmariadb/mariadb_lib.c:3863:7 #2 0x5ceaa4f698fd in mysql_init ./server/libmariadb/libmariadb/mariadb_lib.c:1320:3 #3 0x5ceaa4f5a06f in mariadb_reconnect ./server/libmariadb/libmariadb/mariadb_lib.c:2104:3 #4 0x5ceaa4f58c8b in mthd_my_send_cmd ./server/libmariadb/libmariadb/mariadb_lib.c:394:9 #5 0x5ceaa4f5add5 in ma_simple_command ./server/libmariadb/libmariadb/mariadb_lib.c:472:10 #6 0x5ceaa4f75044 in mysql_send_query ./server/libmariadb/libmariadb/mariadb_lib.c:2524:10 #7 0x5ceaa4efc226 in wrap_mysql_send_query(st_mysql*, char const*, unsigned long) ./server/client/../tests/nonblock-wrappers.h:211:1 #8 0x5ceaa4f2f8ce in run_query_normal(st_connection*, st_command*, int, char const*, unsigned long, st_dynamic_string*, st_dynamic_string*) ./server/client/mysqltest.cc:8230:9 #9 0x5ceaa4f36676 in run_query(st_connection*, st_command*, int) ./server/client/mysqltest.cc:9652:5 #10 0x5ceaa4f3a0ea in main ./server/client/mysqltest.cc:10484:2 #11 0x7efaf322a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #12 0x7efaf322a28a in __libc_start_main csu/../csu/libc-start.c:360:3 #13 0x5ceaa4e1fd44 in _start (./server/build116_asan/client/mariadb-test+0x141d44) (BuildId: 21b3097a37beada873a1eaa15c1ea1f16d3ad6d7)

WORK IN PROGRESS context {select_lex, outer_context} elements made private, accessor function will now skip merged selects. SELECT_LEX::resolved_here contains a list of Item_fields that is resolved in that select. It is used to calculate new_used_tables_cache in Item_subselect::recalc_used_tables. We can compare new/old calculations with (in the correct directory and with the trace file enabled) grep used_tables_cache mysqld.trace It currently works, except when it doesn't, i.e. select * from t1 where t1c in ( select * from ( select t2a from (select * from t2) table2 where t2a in ( select t3a from t3 where t3a in ( select t4a from t4 where t4a < any(select t5c from t5 where t5a > t2a) ) ) ) dt ); resolved_here isn't being correctly set in select #1 after merges. Working on it.

vuvova pushed a commit that referenced this pull request Jun 13, 2014

Addendum #1 to the fix for bug #18359924

ea38c26

Removed unused variable. Fixed long (>80 lines)

vuvova reviewed Jun 13, 2014
View reviewed changes

vuvova self-assigned this Jun 17, 2014

cvicentiu added 2 commits July 6, 2014 14:23

Added default_role column to mysql_system_tables

e9b5611

Added extra error messages for default role.

f13d1a1

Also fixed wording on one message.

cvicentiu added 4 commits July 20, 2014 03:05

Added default role implementation

432827b

Fixed comment.

475d81d

Extended create_and_drop_role_invalid_user_table

7b9dcce

Added extra check for default_role column.

Changed set_default_role_for test to clean up correctly

1f5b71b

vuvova closed this Jul 22, 2014

vuvova pushed a commit that referenced this pull request Feb 12, 2015

Addendum #1 to the fix for bug #18359924

db2403c

Removed unused variable. Fixed long (>80 lines)

spetrunia added a commit that referenced this pull request Oct 10, 2016

MDEV-10975: Merging of @@rocksdb_skip_unique_check: Part #1

f4994c7

Leave the code in, but #ifdef it away to avoid compilation error

elenst added a commit that referenced this pull request Feb 6, 2017

Additional test fixes for MDEV-7635 #1

c574f81

Fix the comment to describe the sequence of events correctly

nirbhayc pushed a commit that referenced this pull request Feb 8, 2017

Additional test fixes for MDEV-7635 #1

834f27f

Fix the comment to describe the sequence of events correctly

spetrunia added a commit that referenced this pull request Aug 8, 2024

MDEV-34720: Poor plan choice for large JOIN with ORDER BY and small L…

6128bfb

…IMIT Part #1: hook into the join optimizer. The choice between index-based access methods is not implemented yet.

spetrunia added a commit that referenced this pull request Aug 12, 2024

MDEV-34720: Poor plan choice for large JOIN with ORDER BY and small L…

26db313

…IMIT Part #1: hook into the join optimizer. The choice between index-based access methods is not implemented yet.

spetrunia added a commit that referenced this pull request Dec 3, 2024

Address review input part #1.

989a828

spetrunia added a commit that referenced this pull request Dec 3, 2024

MDEV-6017: Address review input part #1.

6e818d7

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Default Role Implementation #1

Default Role Implementation #1

cvicentiu commented Jun 6, 2014

vuvova Jun 13, 2014

cvicentiu Jun 13, 2014

vuvova commented Jun 13, 2014

cvicentiu commented Jul 20, 2014

vuvova commented Jul 22, 2014

Default Role Implementation #1

Default Role Implementation #1

Conversation

cvicentiu commented Jun 6, 2014

vuvova Jun 13, 2014

Choose a reason for hiding this comment

cvicentiu Jun 13, 2014

Choose a reason for hiding this comment

vuvova commented Jun 13, 2014

cvicentiu commented Jul 20, 2014

vuvova commented Jul 22, 2014