March 2017 - developers - lists.mariadb.org

Re: [Maria-developers] b6f4d16: MDEV-10436 non-deterministic vcol does not force rbr
by Sergei Golubchik 20 Mar '17

20 Mar '17

Hi, Sachin! On Feb 10, Sachin Setiya wrote: > revision-id: b6f4d16a015fc778186ae4d2c1820a78cd9645d1 (mariadb-10.2.3-157-gb6f4d16) > parent(s): 5285504857df6caf417c8a56601913a95c9f7abc > author: Sachin Setiya > committer: Sachin Setiya > timestamp: 2017-02-10 18:24:12 +0530 > message: > > MDEV-10436 non-deterministic vcol does not force rbr > > Problem:- Since 10.2.1 one can create virtual generated columns with > non-deterministic functions. Arguably, in cases like > INSERT t1 SELECT * FROM t2 > if t2 contains such non-deterministic generated columns and replication > mode is MIXED, the statement should be logged in the row format. But it is > logged in statement format. Some explanation of the fix would be good here. Especially if it's not trivial. Why did you need set_cs_bin_format_row_if_mixed_and_nd_vcol() function and why are you doing something in end_send()? You've fixed THD::decide_logging_format(), why was that not enough? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 2

[Maria-developers] MDEV-12303 Add Type_handler::Item_xxx_fix_length_and_dec()
by Alexander Barkov 20 Mar '17

20 Mar '17

Hello Alexey, Can you please review a patch for MDEV-12303? Thanks!

1 0

Re: [Maria-developers] Filtered transactions coming through mysql/mariadb replication to Galera cluster
by Michael Widenius 20 Mar '17

20 Mar '17

Hi! > Hi, > > Galera cluster (https://github.com/codership/mysql-wsrep/commits/5.6) has new feature : > > commit 14301279075dc2b420f3173cc9c2eb7912db63de > Author: sjaakola <seppo.jaakola(a)iki.fi> > Date: Fri Nov 18 12:45:42 2016 +0200 > > Refs: MW-319 > * replicating write set containing only GTID event of totally filtered transaction > coming in through mysql replication > * note that replicated WS will have no keys, and current debug version of Galera 3.19 > will assert for no keys > > My questions: > > (1) If MySQL (5.6/5.7) replicates transactions to Galera cluster (assuming here that this cluster will contain MariaDB 10.0-10.2 nodes) does the server somehow see filtered GTID events ? > > (2) If MariaDB replicates transactions to Galera cluster are filtered transactions seen by Galera ? What exactly is the definition of filtered transactions? In MariaDB replication, we automatically remove all MySQL GTID's and what the slaves sees is basically a replication stream without any GTID, like it would come from an old slave. The slave will add it's own GTID's to it's own binary log, if logging is enabled. Seppo, is this still the case for new Galera code that will come to MariaDB? If not, what has changed? Regards, Monty

1 0

[Maria-developers] [GSOC] Table functions (aka SQL functions returning tables)
by Pranjal Rai 20 Mar '17

20 Mar '17

Hello, My name is Pranjal and I am a 4th year student at IIIT Hyderabad. I am interested in working on the project MDEV-8100 <https://jira.mariadb.org/browse/MDEV-8100> "Table functions (aka SQL functions returning tables)". I read the description of the task and it is quite clear to me. In the comments it is advised to consider creating TABLE datatype for the task. Is this task along with creation of TABLE datatype doable in the given timeline? Also, can someone please suggest what part of the source code should I read. Regards, Pranjal

2 1

[Maria-developers] prospective GSOC 2017 student [MDEV-7502]
by ibrar arshad 19 Mar '17

19 Mar '17

Hi, My name is Ibrar Arshad and I am interested in working on the task of automatic slave provisioning(ticket: MDEV-7502 <https://jira.mariadb.org/browse/MDEV-7502>) during GSOC 2017. I have read the summary on the ticket and have achieved a fair understanding of the problem and I am working towards ironing out the implementation details. The use-case as I understand is that we want the slave to auto-replicate the data from master once pointed the master and we want to do it in such a manner that the binlog events from current master position as well as the old data chunks are relayed to the slave in a parallel fashion. I have a few questions related to the proposal: 1. After reading a few pages on replication, my understanding is that after "CHANGE MASTER TO" and "START SLAVE", master starts sending binlog events from its current position to the slave which slave starts applying. The usual replication approach is to get the current binlog position on master, backup all the data till this position from master to slave, point slave to this position(or GTID) via "CHANGE MASTER TO", and START SLAVE to start replicating bin events from master. But for MDEV-7502, we want the normal events and old data chunks to be transmitted in parallel. The ticket summary mentions using separate domain_ids to send the new and old data in parallel, does there exist a way to do so currently? How can domain id be used here? Can we currently point the slave to 2 different bin positions on a single master and expect the master to send events from both positions? Or will this require some sort of new process/thread implementation on master to do so? 2. There are at-least two other approaches mentioned in the ticket's comments section. It doesn't seem like that a single approach has been finalized. This project doesn't seem to have a mentor yet to provide guidance so which approach should an applicant pursue further? I would like to discuss the project approaches and implementation further in detail before submitting a proposal so can somebody please answer my queries and further suggest pointers to this project specific material which I can go through to get a deeper understanding? Thanks.

3 2

Re: [Maria-developers] 9f33288dde9: MDEV-11115 CHECK constraints are not shown in I_S.TABLE_CONSTRAINTS
by Sergei Golubchik 16 Mar '17

16 Mar '17

Hi, Jacob! On Mar 16, jacob.mathew(a)mariadb.com wrote: > revision-id: 9f33288dde950343c46e6c5d6a4f233de191f477 (mariadb-10.2.3-245-g9f33288dde9) > parent(s): 7c152ac68a7993bca99ef23e073b0a0974b087a1 > author: Jacob Mathew > committer: Jacob Mathew > timestamp: 2017-03-16 14:41:41 -0700 > message: > > MDEV-11115 CHECK constraints are not shown in I_S.TABLE_CONSTRAINTS > > Add test case: check_constraint_show > > diff --git a/mysql-test/t/check_constraint_show.test b/mysql-test/t/check_constraint_show.test > new file mode 100644 > index 00000000000..0e2f45883df > --- /dev/null > +++ b/mysql-test/t/check_constraint_show.test > @@ -0,0 +1,8 @@ > +# Table with 2 column-level check constraints and 1 table-level check constraint > +create or replace table t1( c1 int, c2 int, c3 int, primary key( c1 > ), constraint `c1_min` check( c1 > 0 ), constraint `c3_min` check( c3 > > 0 ), constraint `range` check( ( c2 >= c1 ) and ( c2 <= c3 ) ) ); > +show create table t1; > + > +# Show all constraints, including check constraints > +select * from information_schema.table_constraints where table_name = 't1'; > + > +drop table t1; This is good, thanks! But please, test column-level constraints too, as I've asked in a review. Something like create table t1 (c1 int check(c1 > 10), c2 int check (c2 < c1), ...) Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] cbfa5f6: MDEV-11177 mysqlbinlog exits silently without error when another
by Sergei Golubchik 15 Mar '17

15 Mar '17

Hi, Alexey! On Mar 13, Alexey Botchkov wrote: > revision-id: cbfa5f6a6d48b3b755462eb0df5e34c63de78f98 (mariadb-10.2.4-46-gcbfa5f6) > parent(s): eded6243bc4796ab44e70403edd059d32225f589 > committer: Alexey Botchkov > timestamp: 2017-03-13 18:26:37 +0400 > message: > > MDEV-11177 mysqlbinlog exits silently without error when another > instance connects to server. > > New thread kill status added KILL_SLAVE_SAME_ID, and the related > error message. > > diff --git a/sql/sql_class.h b/sql/sql_class.h > index 22895d7..986cb1c 100644 > --- a/sql/sql_class.h > +++ b/sql/sql_class.h > @@ -478,16 +478,22 @@ enum killed_state > KILL_TIMEOUT= 8, > KILL_TIMEOUT_HARD= 9, > /* > + When binlog reading thread connects to the server it kills > + all the binlog threads with the same ID. > + */ > + KILL_SLAVE_SAME_ID= 10, > + /* > All of the following killed states will kill the connection > KILL_CONNECTION must be the first of these and it must start with > an even number (becasue of HARD bit)! > */ > - KILL_CONNECTION= 10, > - KILL_CONNECTION_HARD= 11, > - KILL_SYSTEM_THREAD= 12, > - KILL_SYSTEM_THREAD_HARD= 13, > - KILL_SERVER= 14, > - KILL_SERVER_HARD= 15 > + KILL_CONNECTION= 12, > + KILL_CONNECTION_HARD= 13, > + KILL_SYSTEM_THREAD= 14, > + KILL_SYSTEM_THREAD_HARD= 15, > + KILL_SERVER= 16, > + KILL_SERVER_HARD= 17, Okay. I don't really like it, because KILL_CONNECTION/KILL_QUERY is how a user can specify what to kill, and KILL_SLAVE_SAME_ID is not that. But looking at the current enum killed_state, I see that its values already tell * _what_ to kill: KILL_CONNECTION, KILL_QUERY * _how_ to kill: KILL_HARD * _why_ to kill: KILL_TIMEOUT, KILL_SERVER, etc all in one enum. Your KILL_SLAVE_SAME_ID is another one in the "why to kill" list, it adds to this mess, but it doesn't make it much worse, I'd say. This needs to be cleaned up, though. A question - are you sure there enum values are not visible to clients, not part of the API? If you've checked that and they are not - ok to push. If you'd like to clean up KILL_* values (in a separate commit, of course), a very simple change would be to make it into a bitmap. Like first bit is "how to kill" (hard/not hard). Then one bit for "what to kill" - connection/query. The rest is for why. There'll be helpers like #define is_hard_kill(X) ((X) & HARD_KILL_BIT) #define is_kill_query(X) ((X) & KILL_QUERY_BIT) #define is_kill_connection(X) (!is_kill_query(X)) #define kill_reason(X) ((enum kill_reason)((X) >> 2)) Something like that. This doesn't change much internally, only the presentation and the way of thinking about it changes. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] Adding ApplicationName, ClientUser and ClientHostname to Information_schema.processlist
by jerome brauge 14 Mar '17

14 Mar '17

Hello, Apparently, no one is interested by this request. I think it is still interesting for project "MDEV-10137 Providing compatibility to other databases". Major databases allow to see these informations: - master..sysprocesses on Sybase and SQLserver - v$session or gv$session on Oracle - SYSIBMADM.SNAPAPPL_INFO on DB2 LUW - pg_stat_activity on postgresql I can make a patch to add ApplicationName, ClientUser and ClientHostname to Information_schema.processlist. Must I open a feature request on jira and wait your agreement ? Best regards, Jérôme. -----Message d'origine----- De : Maria-developers [mailto:maria-developers-bounces+j.brauge=qualiac.com@lists.launchpad.net] De la part de jerome brauge Envoyé : mardi 7 mars 2017 15:49 À : MariaDB Developers (maria-developers(a)lists.launchpad.net) Objet : [Maria-developers] Adding information de Information_schema.processlist Hello, Connector/J support the method setClientInfo and standard information : ApplicationName, ClientUser and ClientHostname. (https://docs.oracle.com/javase/7/docs/api/java/sql/Connection.html#setClien… It's seem that there is no way to see these information by a select because session variables are used to store these values. Can we add these information as columns in Information_schema.processlist ? Regards, Jérôme. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers(a)lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp

1 0

[Maria-developers] bb-10.2-compatibility - Updatable cursor
by jerome brauge 14 Mar '17

14 Mar '17

Hello Alexander, Can you add a task for updatable cursor (for positioned update and delete). Regards, Jérôme.

2 5

[Maria-developers] Filtered transactions coming through mysql/mariadb replication to Galera cluster
by Jan Lindström 14 Mar '17

14 Mar '17

Hi, Galera cluster (https://github.com/codership/mysql-wsrep/commits/5.6) has new feature : commit 14301279075dc2b420f3173cc9c2eb7912db63de Author: sjaakola <seppo.jaakola(a)iki.fi> Date: Fri Nov 18 12:45:42 2016 +0200 Refs: MW-319 * replicating write set containing only GTID event of totally filtered transaction coming in through mysql replication * note that replicated WS will have no keys, and current debug version of Galera 3.19 will assert for no keys My questions: (1) If MySQL (5.6/5.7) replicates transactions to Galera cluster (assuming here that this cluster will contain MariaDB 10.0-10.2 nodes) does the server somehow see filtered GTID events ? (2) If MariaDB replicates transactions to Galera cluster are filtered transactions seen by Galera ? R: Jan

1 0