- developers - lists.mariadb.org

[Maria-developers] Coverity scanning
by Daniel Black 22 Apr '15

22 Apr '15

Hi, Seems MariaDB has an active Coverity project https://scan.coverity.com/projects/284 ... but it hasn't been looked at for a while. >From my list of bugs I suspect it would of found issues like: * MDEV-7977 * MDEV-7864 * MDEV-4980 In correcting these before release it would of benefited MariaDB by: * Not having SEGV / assertions faults occurring on user machines (even if they where test machines) * hours of time by Elena and me to get a test cases produced for obvious logic bugs -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

2 1

[Maria-developers] MDEV-8024 Remove excessive update_used_tables() calls
by Alexander Barkov 21 Apr '15

21 Apr '15

Hi Sergei, Please review a patch for MDEV-8024. It's needed to as a pre-requisite for "MDEV-7950 Item_func::type() takes 0.26% in OLTP RO" Thanks.

2 1

[Maria-developers] MDEV-8024 Remove excessive update_used_tables() calls
by Alexander Barkov 21 Apr '15

21 Apr '15

Hi Sergei, Please review a patch for MDEV-8024. It's needed to as a pre-requisite for "MDEV-7950 Item_func::type() takes 0.26% in OLTP RO" Thanks.

1 0

[Maria-developers] Need help merging MDEV-7387 from 10.0 to 10.1
by Kristian Nielsen 20 Apr '15

20 Apr '15

Hi Bar, Can you please merge the following patch 10.0 -> 10.1? commit bc902a2bfc46add0708896c07621e3707f66d95f Author: Alexander Barkov <bar(a)mariadb.org> Date: Fri Mar 13 16:12:54 2015 +0400 MDEV-7387 [PATCH] Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1 should fail Eg. run `git merge bc902a2bfc46add0708896c07621e3707f66d95f` in a 10.1 tree. Or alternatively, tell me how to resolve the below conflict in the merge, which is seen in sql/handler.h, so I can do the merge? (This conflict is blocking me from pushing MDEV-7249, MDEV-5289, MDEV-7668, and MDEV-7802 into 10.1...) - Kristian. ----------------------------------------------------------------------- sql/handler.h: <<<<<<< HEAD void init() { bzero(this, sizeof(*this)); } bool tmp_table() const { return options & HA_LEX_CREATE_TMP_TABLE; } void use_default_db_type(THD *thd) { db_type= tmp_table() ? ha_default_tmp_handlerton(thd) : ha_default_handlerton(thd); } }; /** This struct is passed to handler table routines, e.g. ha_create(). It does not include the "OR REPLACE" and "IF NOT EXISTS" parts, as these parts are handled on the SQL level and are not needed on the handler level. */ struct HA_CREATE_INFO: public Table_scope_and_contents_source_st, public Schema_specification_st { void init() { Table_scope_and_contents_source_st::init(); Schema_specification_st::init(); } }; /** This struct is passed to mysql_create_table() and similar creation functions, as well as to show_create_table(). */ struct Table_specification_st: public HA_CREATE_INFO, public DDL_options_st { // Deep initialization void init() { HA_CREATE_INFO::init(); DDL_options_st::init(); } void init(DDL_options_st::Options options) { HA_CREATE_INFO::init(); DDL_options_st::init(options); } /* Quick initialization, for parser. Most of the HA_CREATE_INFO is left uninitialized. It gets fully initialized in sql_yacc.yy, only when the parser scans a related keyword (e.g. CREATE, ALTER). */ void lex_start() { HA_CREATE_INFO::options= 0; DDL_options_st::init(); } ||||||| merged common ancestors bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; } ======= bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; } bool check_conflicting_charset_declarations(CHARSET_INFO *cs); bool add_table_option_default_charset(CHARSET_INFO *cs) { // cs can be NULL, e.g.: CREATE TABLE t1 (..) CHARACTER SET DEFAULT; if (check_conflicting_charset_declarations(cs)) return true; default_table_charset= cs; used_fields|= HA_CREATE_USED_DEFAULT_CHARSET; return false; } bool add_alter_list_item_convert_to_charset(CHARSET_INFO *cs) { /* cs cannot be NULL, as sql_yacc.yy translates CONVERT TO CHARACTER SET DEFAULT to CONVERT TO CHARACTER SET <character-set-of-the-current-database> TODO: Should't we postpone resolution of DEFAULT until the character set of the table owner database is loaded from its db.opt? */ DBUG_ASSERT(cs); if (check_conflicting_charset_declarations(cs)) return true; table_charset= default_table_charset= cs; used_fields|= (HA_CREATE_USED_CHARSET | HA_CREATE_USED_DEFAULT_CHARSET); return false; } >>>>>>> bc902a2bfc46add0708896c07621e3707f66d95f

3 6

Re: [Maria-developers] MariaDB 10 and MaxScale binlog router
by Kristian Nielsen 20 Apr '15

20 Apr '15

Massimiliano Pinto <massimiliano.pinto(a)mariadb.com> writes: First, Massimiliano, please use the maria-developers@ list for all discussions about development on mariadb and related projects. It is very important to keep all communication in the open and work against mariadb becoming a proprietary SkySQL project rather than an open community project. > we started working with MariaDB 10 master & slaves setup with MaxScale > binlog router (which was developed for MySQL 5.6 without GTID support) > Trying first MariaDB 10 setup we found this statement sent from Slave > to Master (maxsacle here) > > > (1) SET @mariadb_slave_capability=4 Check the MARIA_SLAVE_CAPABILITY_* #defines in sql/log_event.h. When connecting, a slave announces its capabilities (which is basically its version). This tells the master about which events are understood by that version of the slave. The master will check each event if it can be handled by the slave. If not, the event will be converted on-the-fly to something the older slave can understand. For example, a MariaDB 5.5 (or MySQL) slave does not understand GTID events. So a MariaDB 10.0 master will convert the GTID event into a BEGIN query event for slaves that have capability < MARIA_SLAVE_CAPABILITY_GTID (4). If you are accepting connections from a slave, you can do the same conversion. If you do not, then older version slaves might break if they receive events generated by newer version master. You can decide which approach makes sense for your project. If you are connecting to a master, then you need to announce your capability. If you do not, you will be interpreted by the master as having an old version, and newer events (like GTID) will be filtered out and not seen. > We soon got another one statement not handled: > > (2) SELECT binlog_gtid_pos('mst-bin.000001',310) This is used by the slave to obtain the correct GTID position corresponding to the position at which it is starting, when it is connecting in non-GTID mode. When the slave has this information, it becomes easy for the DBA to switch to a new master using GTID: STOP SLAVE; CHANGE MASTER TO master_host='new_master', master_use_gtid=slave_pos; START MASTER; This works even if the slave was not using GTID mode prior to the CHANGE MASTER, thanks to that SELECT binlog_gtid_pos(). > we are not handling it (just return the MaxScale default error message > to the connected client) Then the connected client/slave will assume this is an old master that does not support GTID. So the slave will not know the correct GTID position, and the easy CHANGE MASTER above may not be sufficient. Again, maybe that is fine for you, if you do not plan to support GTID. > We would like to hear your point of view, for (1) > @mariadb_slave_capability, how to handle it? What does it mean? Any > possible issues with different values? > Will this prevent us the use of Binlog router with MariADB 10? > > And for (2), is that ok just to ignore it? Would we get issues? I hope the above answers it (else ask again). Basically, you can ignore (1) and return error in (2), and things should work similar to MariaDB 5.5. But there will be reduced functionality compared to MariaDB 10.0/10.1. - Kristian.

3 5

[Maria-developers] Ubuntu Snappy and MariaDB packaging
by Otto Kekäläinen 19 Apr '15

19 Apr '15

Hello! Cool so see a discussion on the list about how to make the most optimal Docker packaging of MariaDB. I also stumbled across that Ubuntu has this completely novel OS structure called Snappy. Please post in this list if any of you start working on a Ubuntu Snappy version of MariaDB packaging.. Snappy packages are basically just a tar package of the binary and files plus a meta.yml description file: https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/

1 0

[Maria-developers] Oracle April security notices and MariaDB
by Otto Kekäläinen 19 Apr '15

19 Apr '15

Hello! Debian security team is pressing me on the information about which recent Oracle CVEs affect MariaDB and which not. They default to assuming all affect so we need to prove otherwise. The Debian CVE tracker: https://security-tracker.debian.org/tracker/source-package/mariadb-10.0 None of these recent CVEs are listed at the MariaDB.org tracker: https://mariadb.com/kb/en/mariadb/security/ Could somebody please update the MariaDB.org CVE overview page? Thanks! Otto

1 0

Re: [Maria-developers] [Commits] eb47b22: MDEV-7820 Server crashes in in my_strcasecmp_utf8 on subquery in ORDER BY clause of GROUP_CONCAT
by Oleksandr Byelkin 15 Apr '15

15 Apr '15

On 15.04.15 15:26, vicentiu(a)mariadb.org wrote: > revision-id: eb47b226d268e7820a9153672798cf991a8fd0fa > parent(s): cc84ac3be41d9d6ac480d55449d5bf4e324cca10 > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-04-15 16:23:43 +0300 > message: > > MDEV-7820 Server crashes in in my_strcasecmp_utf8 on subquery in ORDER BY clause of GROUP_CONCAT > > It is possible for Item_field to have a NULL field_name. This is true if > the Item_field is created based on a field in a temporary table that has > no name. It is thus necessary to do a null check before attempting a > strcmp. Thank you. OK to push. (do not forget to run full test suite) [skip]

1 0

[Maria-developers] CREATE/ALTER USER syntax in MySQL 5.7.5/5.7.6
by Peter Laursen 13 Apr '15

13 Apr '15

Please read MySQL 5.7 documentation on CREATE USER and ALTER USER syntax: https://dev.mysql.com/doc/refman/5.7/en/create-user.html https://dev.mysql.com/doc/refman/5.7/en/alter-user.html (note before/after version 5.7.5/5.7.6 changes) .. as well as this blog: http://mysqlblog.fivefarmers.com/2015/04/10/improved-alter-user-syntax-supp… "With changes made in MySQL Server 5.7.6, a better distinction is made between privilege-level attributes (those which are managed via GRANT and REVOKE statements) and account-level attributes (those managed using CREATE USER and ALTER USER statements). MySQL has a long history of confusing these – for example, requiring a GRANTcommand to set account resource limits or require SSL. " I think this is a very valid observation and thus also change. Does MariaDB have plans to implement the full CREATE/ALTER USER syntax of MySQL 5.7.5/5.7.6? -- Peter -- Webyog

3 2

[Maria-developers] MDEV-7660 - MySQL WL#6671 "Improve scalability by not using thr_lock.c locks for InnoDB tables"
by Sergey Vojtovich 09 Apr '15

09 Apr '15

Hi Jan, we're trying to adapt MySQL WL#6671 to MariaDB, which is expected to boost concurrent single table workloads. MySQL solution is fully based on MDL. It caused substential changes to MDL, which would be nice to avoid. We'd like to understand if we can achieve the same effect with InnoDB locking. According to WL#6671 InnoDB relied on THR_LOCK in following cases: 1. "To isolate HANDLER READ statements from LOCK TABLES WRITE statements." It is likely not a big problem if we decide to go non-MDL way. 2. "To isolate LOCK TABLES statements that lock tables for write implicitly or for read, both explicitly or implicitly, from concurrent DML statements." That's something that we're looking alternatives for. See below. 3. "Due to coding mistake thr_lock.c lock was necessary to isolate ALTER TABLE IMPORT/DISCARD TABLESPACE under LOCK TABLES from concurrent I_S queries/ open HANDLERs." I agree with this patch, it is merged and pending approval (MDEV-7894). 4. "To indicate that InnoDB tables don't support LOCK TABLES READ LOCAL by upgrading TL_READ lock requested by statement to TL_READ_NO_INSERT." It is likely not a big problem if we decide to go non-MDL way. The question is if InnoDB can do the following with reasonable effort: - LOCK TABLES ... READ - protect table data from concurrent writers - LOCK TABLES ... WRITE - pretect table data from concurrent readers and writers - honor SELECT HIGH_PRIORITY when there's pending LOCK TABLES ... WRITE (do we need this?) - honor LOCK TABLES ... WRITE LOW_PRIORITY when there're concurrent readers (do we need this?) Thanks, Sergey

1 0