November 2014 - developers - lists.mariadb.org

[Maria-developers] Fwd: Is it soon 'end of this year'?
by Peter Laursen 04 Nov '14

04 Nov '14

Forwarding to MariaDB developers mailing list. It may be a matter for somebody else than Sergei (Georg, for instance) (and "here" means"Webyog"). Abishek detailed errors in a chat with me "symbols like Snippet mysql_client_find_plugin , Snippet mysql_client_register_plugin are not found" ..exactly like in the MySQL bug report. Do you need a JIRA report with a full test case? -- Peter ---------- Forwarded message ---------- From: Abhishek Kumar Pandey <abhishek.pandey(a)webyog.com> Date: Tue, Nov 4, 2014 at 12:51 PM Subject: Re: [Maria-developers] Is it soon 'end of this year'? To: Peter Laursen <peter_laursen(a)webyog.com> Cc: "team. sqlyog" <team.sqlyog(a)webyog.com>, serg(a)mariadb.org, "team.monyog" <team.monyog(a)webyog.com> I am the developer here working with this. I am facing same problem as reported here- http://bugs.mysql.com/bug.php?id=69204 <http://www.google.com/url?q=http%3A%2F%2Fbugs.mysql.com%2Fbug.php%3Fid%3D69…> . Is the same fix needed in the mariadb library? On Tue, Oct 14, 2014 at 6:58 PM, Peter Laursen <peter_laursen(a)webyog.com> wrote: > You will get to this page: https://edelivery.oracle.com/ > > I think you should use a non-webyog email address. Not sure what Mahesh > did. He downloaded frequently in order to check latest MEM. > > > --Peter > > On Tue, Oct 14, 2014 at 3:26 PM, Peter Laursen <peter_laursen(a)webyog.com> > wrote: > >> You could also try to add the code as described by Sergei. First step is >> if it will compile and connect to servers not usinglain text/LDAP. >> >> -- Peter >> >> On Tue, Oct 14, 2014 at 3:12 PM, Supratik Goswami < >> supratik.goswami(a)webyog.com> wrote: >> >>> On Tue, Oct 14, 2014 at 4:58 PM, Sudhindra Bhat < >>> sudhindra.bhat(a)webyog.com> wrote: >>> >>>> +supratik >>>> >>>> We will check this once we have access to MySQL Enterprise server from >>>> Oracle. >>>> >>>> @supratik, >>>> Do we have the binary for MySQL Enterprise server? A Trial is also >>>> sufficient. >>>> >>> >>> No, I think. You may download it. >>> >>>> >>>> On Tue, Oct 14, 2014 at 2:52 PM, Peter Laursen < >>>> peter_laursen(a)webyog.com> wrote: >>>> >>>>> We need to try this again. I don't rememebr who gave up supporting >>>>> 'clear text plugin' with MariaDB API back in April 2013. Probably it was >>>>> not Sudhindra, Likely Shubhansh or Vishal. @Vishal: do you remember >>>>> anything? >>>>> >>>>> I remember one detail from the old discussion we had with MariaDB. >>>>> They told something like "Once enabled nothing special need to be done to >>>>> support clear text. The client wll automatically detect when the server >>>>> requests the password sent as clear text". This mean as far as I can >>>>> understand that we will - unlke early 11.x version - not need a checkbox in >>>>> the connection manager. >>>>> >>>>> We also need access to a commercial server (TRIAL) from Oracle. Mahesh >>>>> could arrange that. Who can today? >>>>> >>>>> >>>>> -- Peter >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Sergei Golubchik <serg(a)mariadb.org> >>>>> Date: Mon, Oct 13, 2014 at 11:24 PM >>>>> Subject: Re: [Maria-developers] Is it soon 'end of this year'? >>>>> To: Peter Laursen <peter_laursen(a)webyog.com> >>>>> >>>>> >>>>> Hi, Peter! >>>>> >>>>> On Oct 13, Peter Laursen wrote: >>>>> > Thanks .. you probabaly know that I am not a developer rmyself (I >>>>> basically >>>>> > stopped being so when ALGOL died 35 years ago!). I have shared all >>>>> > information with SQLyog developer team and we will look into this >>>>> again. >>>>> >>>>> Sure! Don't hesitate to tell if something won't work for you. >>>>> >>>>> Regards, >>>>> Sergei >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Sudhindra Bhat >>>> >>> >>> >> >

2 1

Re: [Maria-developers] MariaDB 10.0.14 got rid of replication safety warning without warning in release notes?
by Pavel Ivanov 03 Nov '14

03 Nov '14

On Sun, Nov 2, 2014 at 3:27 PM, Michael Widenius <monty(a)mariadb.org> wrote: >>> This is the same order that keys are presented in SHOW CREATE TABLE > > Pavel> Why is it safe to assume that keys have the same order on master and on slave? > > Primary and Unique keys should always be ordered the same way on > master and slave. This is handled by the 'sort_keys()' function that > you can find at: sql/sql_table.cc, line 2770. This function seem to sort only by "type" of the key. If several unique keys have the same "type" according to its classification then they will be in the "original order" as the comment in the function says. And the original order may be different. > The only case when this is not the case, is if you add an unique key > on the slave that was not on the master and there is conflicts when > you insert things because of this key. > > However, if you do this, I would say that you are on your own. > >>> To help engine writes we are constantly adding new test in the storage >>> engine test suite, to make it easier for storage engine vendors to >>> test that their storage engine follows the interface. >>> We have now added a test to check for the correct behaviour for the >>> case of INSERT ... ON DUPLICATE KEY. > > Pavel> This is very interesting. Can you say which test it is and what > Pavel> exactly does it test? Is it present in 10.0.14 or it's only at the > Pavel> latest 10.0 branch? > > I added a test for this to: > mysql-test/t/insert.test > > --echo # > --echo # MDEV-5168: Ensure that we can disable duplicate key warnings > --echo # from INSERT IGNORE > --echo # This test doesn't check which duplicate key is asserted to execute ON DUPLICATE KEY action. > Elena added another test for this in > mysql-test/suite/storage_engine/insert_with_keys.test > > See line 142, that start with: > --let $create_definition = a $int_indexed_col UNIQUE KEY, b $int_indexed_col UNIQUE KEY, c $int_col This test seem to check that UPDATE is executed on the correct duplicate key, but it's not executed during regular mtr run. How and when it's executed in MariaDB? >>> Do you have or use a storage engine that doesn't provide the expected value >>> for the conflicting key ? > > Pavel> I don't have a specific example of storage engine that detects > Pavel> duplicate key in different order, but I'm not convinced and don't have > Pavel> hard proof that such engine cannot exist and that InnoDB itself is not > Pavel> susceptible to this problem. I can easily imagine though that even > Pavel> given the particular order of keys in table definition the key > Pavel> reported as having duplicate can depend on the way storage engine > Pavel> stores those keys. > > As key order is defined on the upper level, above InnoDB, this should > be 100 % safe (at least for InnoDB). > > For other store engines, this is safe for any engine that test for > duplicate key in key order. > > If we ever find a case where it's not safe with any storage engine > that we deliver with MariaDB, we will fix the storage engine. > > It's ok if they do thing differently so that they can detect duplicate > key for other keys faster. > > However, it has been required from all storage engines from start that > if one calls 'handler->info()' to request which key was duplicated, > they must return the first key. > > If not, they are breaking the storage engine interface (both for MySQL > and MariaDB) as there is no way the upper level can guarantee that > things will work identically between storage engines. > > Pavel> BTW, can you point to MySQL documentation and/or comment in the code > Pavel> that indicates this requirement to storage engine implementation? > > Most of the storage engine interface is not 100 % documented. This is > one of the case. > However, I wrote the code related to errkey and this is how it was > supposed to work. > In general if something is not documented, then it's up to the people > that created the interface or are actively working on it to define how > it should work. > > What is important is that all storage engine should work the same > way. If one returns something different compared to any of the > existing engines then it's a bug. > > In this case the implicit documentation is how MyISAM, Aria and InnoDB > works. All of them returns the first conflicting key. I'm sorry to say, but you've explained exactly the reason why this behavior is not guaranteed and can be changed at any time. Yes, I understand that when you wrote the interface you had some particular requirements in mind. But ultimately it's up to people actively working on the code (who I believe are counted by hundreds now) to decide whether to maintain the particular behavior or change it. And as nobody knows the original requirements and the reasons why they can't be changed, and when the behavior is not tested anywhere and doesn't have any documentation even in the weakest form of comments or asserts, the decision is usually very easy -- change at will, nobody should ever depend on implementation details. Even if you promise to fix storage engines that change this behavior, by the time you notice the change you'll likely won't be able to fix it (as e.g. in case of https://mariadb.atlassian.net/browse/MDEV-6916) or someone will already experience a data corruption. I'd strongly recommend to revert this change. Thank you, Pavel

1 0

[Maria-developers] MDEV-5528 Command line variable to choose MariaDB-5.3 vs MySQL-5.6 temporal data formats
by Alexander Barkov 03 Nov '14

03 Nov '14

Hello Ian, I've pushed MDEV-5528 into 10.1. I guess it will need some documenting. Can you please have a look? Thanks.

1 0

[Maria-developers] nginx sources in mroonga
by Alexander Barkov 03 Nov '14

03 Nov '14

Hi Kentoku, Sergei Golubchik is asking why we have complete nginx sources inside mroonga? Can you remove them please? Thanks.

3 2