April 2015 - developers - lists.mariadb.org

Re: [Maria-developers] [server] MDEV-7130 MASTER_POS_WAIT does not respect timeout when connection_name is specificed (#32)
by Kristian Nielsen 24 Apr '15

24 Apr '15

f4rnham <notifications(a)github.com> writes: > https://mariadb.atlassian.net/browse/MDEV-7130 > MASTER_POS_WAIT(log_name,log_pos,timeout,"connection_name") hangs, does not respect the timeout > > Changed also arg_count check for connection_name to prevent same bug if fifth argument is introduced in future > > Tests can be reduced to just one master_pos_wait select, it may be better since each this select waits one second timeout (except one for non-existing connection, line 23) Right, I cleaned up the test case and integrated it into the existing rpl.rpl_master_pos_wait test. Pushed into 10.0, thanks f4rnham! - Kristian.

1 0

[Maria-developers] TRUE vs true (was: [Commits] ac05f41: postreview fix)
by Oleksandr Byelkin 24 Apr '15

24 Apr '15

Hi, Jan! On 23.04.15 08:38, Jan Lindström wrote: > Sanja, > > Why you use TRUE/FALSE instead of true/false for bool ? Historical reasons. I was told to use TRUE/FALSE long time ago and nobody have told something else. We have no our code style doc so I use what I remember from old MySQL one. [skip]

4 6

[Maria-developers] MDEV-7649 wrong result when comparing utf8 column with an invalid literal
by Alexander Barkov 22 Apr '15

22 Apr '15

Hi Sergei, I tested comparison behaviour for various different situations. Please find the comment with the summary table in the end of: https://mariadb.atlassian.net/browse/MDEV-7649 Currently there are 5 possible reactions on bad bytes on comparison, depending on the collation, presence of an index, and character_set_connection value: - truncate on bad byte, compare only the well-formed prefix (#1) - treat bad bytes as '?' (#7 and #8) - empty set with no warning (#3) - empty set with a warning (#2) - error (#5 and #6) I'm in doubts what to dofor 10.1 and for 5.5. Please suggest. 1. For 10.1 or 10.2 I think it would be nice to make all these cases work exactly the same way. I am not sure which way would be the best. Any ideas? 2. For 5.5 we need to fix the bug with minimal changes. Do you agree? I suggest we fix only #1 and maybe #2. How we fix 5.5 now should probably depend on how we'll fix 10.1, to avoid changing behaviour many times. Please suggest. Thanks.

2 3

[Maria-developers] packaging code - mariadb and jemalloc.
by Daniel Black 22 Apr '15

22 Apr '15

Daniel, or anyone else. Where is the source/build code for the jemalloc build in the mariadb repo (specifically for ubuntu)? Where is the code that triggers making the rpm and deb packages that form the current mariadb and galera releases? My goal is to get these packages whitelisted by travis-ci so container builds of mariadb and running mtr on github pull rquests/branches can occur for everyone without a buildbot. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

2 3

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

22 Apr '15

Seems there are a fair few variables and options changed in the course of development. These don't seem to make it to the documentation, especially pages like: https://mariadb.com/kb/en/mariadb/server-system-variables/ https://mariadb.com/kb/en/mariadb/server-status-variables https://mariadb.com/kb/en/mariadb/mysqld-options And their per subsection equivalents. Please make an effort to add/update these pages after a commit. After all, if a user can't see a change is made, or is referring to out of date documentation, then they aren't making use of the effort you put into making a change. If you made the change you are in the best position to describe it. git log sql/sys_vars.cc has quite a number of examples including 2ab49689c689b1c1daeb080ea568c268c5256952 cdb8e6ed38ce641a6cb90a4a93bc5ff15f3ba9f2 a978bdda1e2de35c79e432f026869e163657a263 -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

[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