- developers - lists.mariadb.org

Re: [Maria-developers] Fwd: [Commits] Rev 3335: Fix bug lp:825075 in file:///home/tsk/mprog/src/5.3/
by Sergei Petrunia 17 Feb '12

17 Feb '12

Hi Timour, Feedback follows skype discussion: First, here's a general comment Consider a query: SELECT b, min(a) FROM t1 GROUP BY b; Suppose there is an index (b,a). Loose scan would execute it as follows: S00 h->index_first(); S01 produce an output record of (b, a) // first value of 'a' is the minimum S02 S03 h->read_next_different_b(); // Jump to the next GROUP-BY group. S04 ... S05 If we modify the query by adding a WHERE: SELECT b, min(a) FROM t1 WHERE arbitrary_cond(a,b) GROUP BY b; then LooseScan (in its current form) will be unable to execute it. The problem is here: S00 h->index_first(); S01 produce an output record of (b, a) // first value of 'a' is the minimum ^^^ what if this record doesn't match the WHERE? We'll have to scan further within the record having b=first_record.b until we find a match. LooseScan executor doesn't support such "walk forward" action currently. If the WHERE clause has been converted into a range, such that there are no records that would be contained in the range but not match the WHERE clause (***) then LooseScan is able to handle it. Example: SELECT b, min(a) FROM t1 WHERE a>10 GROUP BY b; Execution would proceed as follows: S00 h->index_first(); S00 h->index_read(HA_READ_AFTER_KEY, {current_row.b, 'a>10'}) S01 produce an output record of (b, a) // first value of 'a>10' is the minimum Step S01 will produce correct results as long as the following holds: "The first record we've got in a range will satisfy the WHERE condition" This is not always the case. Here's a counterexample: SELECT b, min(a) FROM t1 WHERE a>10 GROUP BY b; SELECT b, min(a) FROM t1 WHERE a>10 and ((a MOD 2) = 0) GROUP BY b; -- (C1) Consider the second query and this dataset: b , a 1, 5 1, 7 1, 11 1, 13 1, 14 range optimizer would give a range of "a > 10", and the first matching record is (1,11). It doesn't satisfy the "(a MOD 2)=0" condition, neither does the next record of (1,13), and only the record (1,14) will satisfy the MOD part of the condition. The problem: current code doesn't seem to have the logic to detect such cases. The submitted patch disables LooseScan for apparently invalid cases where the WHERE condition covers a column while range condition does not, which means that condition (***) is certainly unmet. However, cases like (C1) are still not handled. Further comments are inline. On Wed, Dec 07, 2011 at 02:18:02PM +0200, Timour Katchaounov wrote: > Could you please review the below patch. > > Timour > > ----------------------------------------------------------- > revno: 3335 > revision-id: timour(a)askmonty.org-20111207115332-3oa536gbt20r22po > parent: igor(a)askmonty.org-20111206214218-lev0vyidyt8h3431 > fixes bug(s): https://launchpad.net/bugs/825075 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Wed 2011-12-07 13:53:32 +0200 > message: > Fix bug lp:825075 > > Analys: > The cause for the wrong result was that the optimizer > incorrectly chose min/max loose scan when it is not > applicable. The applicability test missed the case when > a condition on the MIN/MAX argument was OR-ed with a > condition on some other field. In this case, the MIN/MAX > condition cannot be used for loose scan. > > Solution: > The function check_group_min_max_predicates() duplicated > functionality performed by the range optimizer, but this > duplication was incomplete. The solution is to reuse instead > the analys and the ranges produced by the range optimizer. > If a suitable range could not be extracted for the MIN/MAX > argument, then loose scan is not applicable. > === modified file 'mysql-test/r/group_min_max.result' > --- a/mysql-test/r/group_min_max.result 2011-12-04 21:31:42 +0000 > +++ b/mysql-test/r/group_min_max.result 2011-12-07 11:53:32 +0000 > @@ -2103,7 +2103,7 @@ id select_type table type possible_keys > explain select a1,a2,b,min(c),max(c) from t2 > where (c > 'a000') and (c <= 'd999') and (c like '_8__') group by a1,a2,b; > id select_type table type possible_keys key key_len ref rows Extra > -1 SIMPLE t2 index NULL idx_t2_1 163 NULL 164 Using where; Using index > +1 SIMPLE t2 range NULL idx_t2_1 163 NULL 33 Using where; Using index for group-by > explain select a1, a2, b, c, min(d), max(d) from t1 group by a1,a2,b,c; > id select_type table type possible_keys key key_len ref rows Extra > 1 SIMPLE t1 ALL NULL NULL NULL NULL 128 Using temporary; Using filesort Why there is no testcase from the bug report? I think it's better to have a testcase that - will explicitly mention BUG# - will show the wrong query result. A changed EXPLAIN in some irrelevant test is a too poor coverage. > === modified file 'sql/opt_range.cc' > --- a/sql/opt_range.cc 2011-11-18 17:35:51 +0000 > +++ b/sql/opt_range.cc 2011-12-07 11:53:32 +0000 > @@ -11984,164 +11996,41 @@ get_best_group_min_max(PARAM *param, SEL > } > > > -/* > - Check that the MIN/MAX attribute participates only in range predicates > - with constants. > - > - SYNOPSIS > - check_group_min_max_predicates() > - cond tree (or subtree) describing all or part of the WHERE > - clause being analyzed > - min_max_arg_item the field referenced by the MIN/MAX function(s) > - min_max_arg_part the keypart of the MIN/MAX argument if any > - > - DESCRIPTION > - The function walks recursively over the cond tree representing a WHERE > - clause, and checks condition (SA3) - if a field is referenced by a MIN/MAX > - aggregate function, it is referenced only by one of the following > - predicates: {=, !=, <, <=, >, >=, between, is null, is not null}. > +/** > + Find the range tree for the field that is an argument of MIN/MAX. > > - RETURN > - TRUE if cond passes the test > - FALSE o/w > + @param cond The WHERE clause of the query > + @param min_max_arg_item The field referenced by the MIN/MAX function(s) > + @param index_tree Range tree for the chosen index > + > + @note > + The function iterates over the range trees for each keypart of the > + chosen index until it finds the range for the MIN/MAX keypart. > + > + @retval > + If there is a range for the MIN/MAX argument > + @retval > + NULL if there is no range > */ > > -static bool > -check_group_min_max_predicates(Item *cond, Item_field *min_max_arg_item, > - Field::imagetype image_type) > +static SEL_ARG * > +get_min_max_range(Item *cond, Item_field *min_max_arg_item, SEL_ARG *index_tree) > { > - DBUG_ENTER("check_group_min_max_predicates"); > - DBUG_ASSERT(cond && min_max_arg_item); > - > + if (!cond || !min_max_arg_item) > + return NULL; > cond= cond->real_item(); So we've got: get_min_max_range(Item *cond, Item_field *min_max_arg_item, SEL_ARG *index_tree) { if (!cond || !min_max_arg_item) return NULL; cond= cond->real_item(); 'cond' is passed as parameter, checked, modified, and .. then never used in the function. Please fix this. > - Item::Type cond_type= cond->real_type(); > - if (cond_type == Item::COND_ITEM) /* 'AND' or 'OR' */ > - { > - DBUG_PRINT("info", ("Analyzing: %s", ((Item_func*) cond)->func_name())); > - List_iterator_fast<Item> li(*((Item_cond*) cond)->argument_list()); > - Item *and_or_arg; > - while ((and_or_arg= li++)) > - { > - if (!check_group_min_max_predicates(and_or_arg, min_max_arg_item, > - image_type)) > - DBUG_RETURN(FALSE); > - } > - DBUG_RETURN(TRUE); > - } > - > - /* > - Disallow loose index scan if the MIN/MAX argument field is referenced by > - a subquery in the WHERE clause. > - */ > - > - if (cond_type == Item::SUBSELECT_ITEM) > - { > - Item_subselect *subs_cond= (Item_subselect*) cond; > - if (subs_cond->is_correlated) > - { > - DBUG_ASSERT(subs_cond->upper_refs.elements > 0); > - List_iterator_fast<Item_subselect::Ref_to_outside> > - li(subs_cond->upper_refs); > - Item_subselect::Ref_to_outside *dep; > - while ((dep= li++)) > - { > - if (dep->item->eq(min_max_arg_item, FALSE)) > - DBUG_RETURN(FALSE); > - } > - } > - DBUG_RETURN(TRUE); > - } > - > /* > - Condition of the form 'field' is equivalent to 'field <> 0' and thus > - satisfies the SA3 condition. > + Extract the SEL_ARG subtree that contains only ranges for the MIN/MAX > + attribute. > */ > - if (cond_type == Item::FIELD_ITEM) > + SEL_ARG *min_max_range= index_tree; > + while (min_max_range) /* Find the tree for the MIN/MAX key part. */ > { > - DBUG_PRINT("info", ("Analyzing: %s", cond->full_name())); > - DBUG_RETURN(TRUE); > - } > - > - /* We presume that at this point there are no other Items than functions. */ > - DBUG_ASSERT(cond_type == Item::FUNC_ITEM); > - > - /* Test if cond references only group-by or non-group fields. */ > - Item_func *pred= (Item_func*) cond; > - Item **arguments= pred->arguments(); > - Item *cur_arg; > - DBUG_PRINT("info", ("Analyzing: %s", pred->func_name())); > - for (uint arg_idx= 0; arg_idx < pred->argument_count (); arg_idx++) > - { > - cur_arg= arguments[arg_idx]->real_item(); > - DBUG_PRINT("info", ("cur_arg: %s", cur_arg->full_name())); > - if (cur_arg->type() == Item::FIELD_ITEM) > - { > - if (min_max_arg_item->eq(cur_arg, 1)) > - { > - /* > - If pred references the MIN/MAX argument, check whether pred is a range > - condition that compares the MIN/MAX argument with a constant. > - */ > - Item_func::Functype pred_type= pred->functype(); > - if (pred_type != Item_func::EQUAL_FUNC && > - pred_type != Item_func::LT_FUNC && > - pred_type != Item_func::LE_FUNC && > - pred_type != Item_func::GT_FUNC && > - pred_type != Item_func::GE_FUNC && > - pred_type != Item_func::BETWEEN && > - pred_type != Item_func::ISNULL_FUNC && > - pred_type != Item_func::ISNOTNULL_FUNC && > - pred_type != Item_func::EQ_FUNC && > - pred_type != Item_func::NE_FUNC) > - DBUG_RETURN(FALSE); > - > - /* Check that pred compares min_max_arg_item with a constant. */ > - Item *args[3]; > - bzero(args, 3 * sizeof(Item*)); > - bool inv; > - /* Test if this is a comparison of a field and a constant. */ > - if (!simple_pred(pred, args, &inv)) > - DBUG_RETURN(FALSE); > - > - /* Check for compatible string comparisons - similar to get_mm_leaf. */ > - if (args[0] && args[1] && !args[2] && // this is a binary function > - min_max_arg_item->result_type() == STRING_RESULT && > - /* > - Don't use an index when comparing strings of different collations. > - */ > - ((args[1]->result_type() == STRING_RESULT && > - image_type == Field::itRAW && > - ((Field_str*) min_max_arg_item->field)->charset() != > - pred->compare_collation()) > - || > - /* > - We can't always use indexes when comparing a string index to a > - number. > - */ > - (args[1]->result_type() != STRING_RESULT && > - min_max_arg_item->field->cmp_type() != args[1]->result_type()))) > - DBUG_RETURN(FALSE); > - } > - } > - else if (cur_arg->type() == Item::FUNC_ITEM) > - { > - if (!check_group_min_max_predicates(cur_arg, min_max_arg_item, > - image_type)) > - DBUG_RETURN(FALSE); > - } > - else if (cur_arg->const_item()) > - { > - /* > - For predicates of the form "const OP expr" we also have to check 'expr' > - to make a decision. > - */ > - continue; > - } > - else > - DBUG_RETURN(FALSE); > + if (min_max_range->field->eq(min_max_arg_item->field)) > + break; > + min_max_range= min_max_range->next_key_part; > } > - > - DBUG_RETURN(TRUE); > + return min_max_range; > } > > BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 2

[Maria-developers] MariaDB 5.3.4 release status
by Sergei Petrunia 15 Feb '12

15 Feb '12

Hi, I've pushed the last bug fix slated for MariaDB 5.3.4, so revno:3419 has a chance to become the 5.3.4 release. It is currently building in buildbot. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

3 7

Re: [Maria-developers] [Commits] Rev 3421: Counters for Index Condition Pushdown added (MDEV-130). in file:///home/bell/maria/bzr/work-maria-5.3-MDEV-130/
by Sergei Petrunia 15 Feb '12

15 Feb '12

Hi Sanja, On Wed, Feb 15, 2012 at 04:13:54PM +0200, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.3-MDEV-130/ > > ------------------------------------------------------------ > revno: 3421 > revision-id: sanja(a)montyprogram.com-20120215141351-rk4pi025utdztzt8 > parent: holyfoot(a)askmonty.org-20120214120406-02q2mv2t6xb37dno > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.3-MDEV-130 > timestamp: Wed 2012-02-15 16:13:51 +0200 > message: > Counters for Index Condition Pushdown added (MDEV-130). OK to push. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] Failure in plugins.feedback_plugin_send
by Kristian Nielsen 14 Feb '12

14 Feb '12

Hi Serg, 5.5 Buildbot is getting greener, but there are still a couple of random failures left. One of them is in plugins.feedback_plugin_send: ----------------------------------------------------------------------- plugins.feedback_plugin_send w1 [ fail ] Test ended at 2012-02-12 00:41:06 CURRENT_TEST: plugins.feedback_plugin_send --- /home/buildbot/build/mysql-test/suite/plugins/r/feedback_plugin_send.result 2012-02-11 21:14:54.336622000 +0200 +++ /home/buildbot/build/mysql-test/suite/plugins/r/feedback_plugin_send.reject 2012-02-12 00:41:05.785412054 +0200 @@ -9,7 +9,4 @@ FEEDBACK_SEND_TIMEOUT 60 FEEDBACK_URL http://mariadb.org/feedback_plugin/post FEEDBACK_USER_INFO mysql-test -feedback plugin: report to 'http://mariadb.org/feedback_plugin/post' was sent -feedback plugin: server replied 'ok' -feedback plugin: report to 'http://mariadb.org/feedback_plugin/post' was sent -feedback plugin: server replied 'ok' +feedback plugin: failed to send report to 'http://mariadb.org/feedback_plugin/post' mysqltest: Result length mismatch ----------------------------------------------------------------------- Any ideas? The test has been failing for a while, though rarely (but maybe some of the past failures have been fixed): http://buildbot.askmonty.org/buildbot/reports/cross_reference#branch=&revis… - Kristian.

2 1

[Maria-developers] Please try new fulltext storage engine "mroonga"
by Kazuhiko Shiozaki 07 Feb '12

07 Feb '12

Hello ! I would like to introduce a new fulltext storage engine "mroonga", that will be included in the future MariaDB release. Mroonga is a fulltext storage engine having the following characteristics: * CJK ready fulltext search * no read lock * faster than MyISAM for both indexing and searching * geolocalazation search is also supported Current development branch is : https://code.launchpad.net/~maria-captains/maria/mariadb-5.3-monty Further information about mroonga can be found : https://kb.askmonty.org/en/about-mroonga You can also see some presentations : http://mroonga.github.com/publication/ I sincerely ask you to try mroonga, at least compile and run tests, on various platforms, like the following procedure. (get source tree) $ ./BUILD/compile-pentium-max (wait for a while) $ cd mysql-test $ ./mtr --suite=mroonga_storage,mroonga_wrapper --force If you find any problem like compilation error, test failure, or whatever, please let me know. Thanks in advance ! -- Kazuhiko Shiozaki, Nexedi SA Senior Consultant Nexedi: Consulting and Development of Free / Open Source Software http://www.nexedi.co.jp/ ERP5: Full Featured High End Open Source ERP http://www.erp5.com/

1 0

[Maria-developers] New KB Question: SSL with other Clients than the original MariaDB-client?
by Daniel Bartholomew 03 Feb '12

03 Feb '12

A new question has been posted to the Knowledgebase. http://kb.askmonty.org/en/ssl-with-other-clients-than-the-original-mariadb-… ==================== It seems to be that there is a difference in handling the SSL handshake at the MariaDB-Server (5.2 or below) in contrast to the Mysql-Server 5.1. All JDBC-Clients can sucessfully connect to the Mysql-Server 5.1 via SSL, but with MariaDB-Server not. Without SSL all JDBC-Clients can sucessfully connect to MariaDB. Both server run with the same CA-, Server- and Client-Certificates and I have made the following tests (all with MariaDB Server 5.2.10 and also tested with 5.1.60 from the Deb-Repository): * Mysql-Client (5.1) cannot connect to MariaDB Server: "ERROR 2026 (HY000): SSL connection error" * Mysql-connector/J cannot connect to MariaDB Server: TLSv1 Handshake fails with "unexpected message" after ClientHello * Drizzle JDBC cannot connect to MariaDB-Server: TLSv1 Handshake fails also with "unexpected message" after ClientHello * Original MariaDB-Client (5.2) can connect easily via SSL with the CA-Certificate to MariaDB-Server. It seems to be a general communication problem in the SSL-Handshake after ClientHello. Is it a bug or a feature? Debug-Log of Java: <<fixed>> trigger seeding of SecureRandom done seeding SecureRandom Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false %% No cached client session ClientHello, TLSv1 RandomCookie: GMT: 1328138424 bytes Session ID: {} Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, \\TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, \\TLS_DHE_DSS_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, \\SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, \\SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, \\ SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, \\SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, \\SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] \\ Compression Methods: { 0 } \\ [write] MD5 and SHA1 hashes: len = 75 \\ main, WRITE: TLSv1 Handshake, length = 75 \\ [Raw write]: length = 80 \\ [Raw read]: length = 5 \\ 0000: 16 00 00 02 FF .....\\ main, handling exception: javax.net.ssl.SSLException: Unsupported record version Unknown-0.0\\ main, SEND TLSv1 ALERT: fatal, description = unexpected_message\\ main, WRITE: TLSv1 Alert, length = 2\\ <</fixed>> ==================== Thanks! -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] New KB Question: How can I install the pam_authentication plugin in deb based system?
by Daniel Bartholomew 01 Feb '12

01 Feb '12

A new question has been posted in the Knowledgebase: How can I install the pam_authentication plugin in deb based system? http://kb.askmonty.org/en/how-can-i-install-the-pam_authentication-plugin-i… ========== Hi all, I've been reading the pam_auth plugin howto: https://kb.askmonty.org/en/pam-authentication-plugin MariaDB [test]> INSTALL PLUGIN pam SONAME 'auth_pam.so'; ERROR 1126 (HY000): Can't open shared library '/usr/lib/mysql/plugin/auth_pam.so' (errno: 2 cannot open shared object file: No such file or directory) Indeed that file does not exist on the system. Nor does the pam_mariadb_mtr.so file. I installed mariadb-server-5.2 using the deb repos on Ubuntu 10.04 64bit (Lucid). Is there any deb archive to include those files in binary? Or do I have to resort to source compilation? ========== Thanks! -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] Preparing to release MariaDB 5.3.4-rc
by Daniel Bartholomew 31 Jan '12

31 Jan '12

All, Monty has informed me that we are ready to release MariaDB 5.3.4-rc. I'm uploading the packages to the primary mirror now and if all goes well the general release announcement will go out tomorrow morning (my time). The source tree has not been tagged yet but the release is from revision 3402: http://bazaar.launchpad.net/~maria-captains/maria/5.3/changes To all the devs: If there is anything notable which I should make sure to include in the release notes, please let me know ASAP. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] Is our annotate_rows_log_event same as mysql-5.6's?
by Kristian Nielsen 31 Jan '12

31 Jan '12

Sergei Petrunia <psergey(a)askmonty.org> writes: > Also, it seems that right now binary logs are not compatible between mysql-5.6 > and mariadb-5.3. When I try read one file with mysqlbinlog of the other I get > this: > > > mariadb-5.3 reading binlog from mysql-5.6 > #120131 2:43:14 server id 1 end_log_pos 295 Query thread_id=2 exec_time=0 error_code=0 > SET TIMESTAMP=1327963394/*!*/; > BEGIN > /*!*/; > ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 62, event_type: 29 > ERROR: Could not read entry at offset 295: Error in log format or read error. Yes, 29 is ROWS_QUERY_LOG_EVENT, their version of annotate_rows_log_event. I think you will find the same problem if you try to read with MySQL 5.1 or 5.5. I believe this only happens if you enable row annotation events on the master; it seems a general thing that if one enables a new feature on a MySQL master, it breaks old slaves. However, when we merge 5.6, we get the new IGNORABLE_LOG_EVENT flag, which allows a newer master (eg. 5.7) to inform an old slave that it is ok to ignore a specific event. When we merge 5.6, I suppose we will just make sure MariaDB 5.6 writes the MySQL event code on the master, and understands the MariaDB event code on the slave, so this will be solved. > Mysql 5.6 reading mariadb-5.3 > ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 48, event_type: -96 > ERROR: Could not read entry at offset 503: Error in log format or read error. > # at 434 > #120131 2:01:47 server id 1 end_log_pos 503 Query thread_id=1 exec_time=0 error_code=0 > SET TIMESTAMP=1327960907/*!*/; > BEGIN And this is the reverse situation, -96 is our ANNOTATE_ROWS_EVENT, which is not understood by MySQL. Again, this only happens when row annotation is explicitly enabled on the master, so one should not do this when having old slaves connected (whether MySQL or MariaDB). There is a deeper issue here. It is not possible on the master to simply filter out the events that an old slave does not understand, as would seem natural. Because the current slave code gets confused when there are "holes" in the binlog positions it receives from the master. In MariaDB 5.5 this will be fixed (if I'm allowed to push MWL#234 ...), allowing a MariaDB slave to adjust binlog positions correctly if the master filters out events. But this does not help MySQL slaves of course. Also, global transaction IDs, which MySQL@Oracle says they are working on, should fix this, but this is not in 5.6 currently. Thanks for taking up these subjects, it's good to get them more clearly understood! - Kristian.

1 0

Re: [Maria-developers] Is our annotate_rows_log_event same as mysql-5.6's?
by Kristian Nielsen 31 Jan '12

31 Jan '12

Sergei Petrunia <psergey(a)askmonty.org> writes: > I see MySQL have added an analog ours > http://kb.askmonty.org/en/annotate_rows_log_event > > http://dev.mysql.com/doc/refman/5.6/en/replication-options-binary-log.html#… > > The names of the options are different: binlog_annotate_row_events vs. binlog_rows_query_log_events > Questions (I assume you can answer them off the top of the head, if not, let's > first discuss it) > > - Is it true that they have re-implemented the feature after we did? Yes. > - Do I understand correctly that the features are not compatible? (different > event code) Yes. However, I checked the MySQL version some time ago. It is extremely similar to our version. I believe it will be quite feasible when merging to make them compatible, eg. just translate the event code from one to the other. Maybe we will just merge the MySQL version for compatibility (MySQL developers do not seem to care about compatibility themselves), and then just add backwards and forwards compatibility translation so we work with old versions of MariaDB. > - Do these features do the same thing or one is better than the other in some > respect? As I remember, they are essentially identical. - Kristian.

1 0