- developers - lists.mariadb.org

Re: [Maria-developers] Fwd: some question on bundled libedit in mysql
by Sergei Golubchik 25 Feb '13

25 Feb '13

Hi, AL13N! On Feb 25, AL13N wrote: > > > > In MariaDB we prefer to link with readline. We never link with bundled > > libedit at all. Either with system readline, if it's usable, or with > > system libedit, or with bundled readline. > > iinm, MariaDB is GPLv2 and libreadline (version 6) is GPLv3, so they don't > mix. but bundled libreadline (version 5) is GPLv2 and that one is > possible. That's why I said "with system readline, if it's usable". We only link with system readline if it's V5 or earlier. Regards, Sergei

1 0

[Maria-developers] Fwd: some question on bundled libedit in mysql
by xiaobing jiang 25 Feb '13

25 Feb '13

hi all: No reply from jonathan.perkin, so post to the maillist. can some one explain to me? Thanks! ---------- Forwarded message ---------- From: xiaobing jiang <s7v7nislands(a)gmail.com> Date: Fri, Feb 22, 2013 at 3:52 PM Subject: some question on bundled libedit in mysql To: jonathan.perkin(a)oracle.com hi jonathan: after read the README in source, I have some question about libedit. in recently, we find a bug. when using bundled libedit, we can't input the chinese using GBK. after debug, I find this code may be cause the bug. protected int terminal__putc(EditLine *el, Int c) { char buf[MB_LEN_MAX +1]; ssize_t i; mbstate_t state; memset(&state, 0, sizeof(mbstate_t)); if (c == (Int)MB_FILL_CHAR) return 0; i = ct_encode_char(buf, (size_t)MB_CUR_MAX, c, &state); // this should be: ct_encode_char(buf, (size_t)MB_LEN_MAX, c, &state); if (i <= 0) return (int)i; buf[i] = '\0'; return fputs(buf, el->el_outfile); } after change the code, I can fix the bug. and I find upstream also using MB_LEN_MAX. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/terminal.c protected int terminal__putc(EditLine *el, Int c) { char buf[MB_LEN_MAX +1]; ssize_t i; if (c == (Int)MB_FILL_CHAR) return 0; i = ct_encode_char(buf, (size_t)MB_LEN_MAX, c); if (i <= 0) return (int)i; buf[i] = '\0'; return fputs(buf, el->el_outfile); } so the merge from upstream may be wrong. And this bug may be the same http://bugs.mysql.com/bug.php?id=23097 and why mysql5.6 remove the bundled readline? I think readline is used more than libedit. and when using system readline, why perfer libedit to readline ? look at cmake/readline.cmake. FIND_SYSTEM_LIBEDIT(edit) -> FIND_SYSTEM_LIBEDIT(readline) thanks! xiaobing jiang

2 1

[Maria-developers] understanding commit and prepare APIs in MariaDB 5.5
by Zardosht Kasheff 21 Feb '13

21 Feb '13

Hello all, I am investigating what our storage engine, TokuDB, needs to do to achieve its best performance in MariaDB 5.5 with respect to preparing and committing transactions, and with respect to binary logging. As I understand, group commit has been added to the binary log in Maria 5.3, and is also in MariaDB 5.5. Additionally, new APIs prepare_ordered and commit_ordered are added. I am trying to understand how these fit together. >From reading http://kristiannielsen.livejournal.com/12408.html and comments in handler.h, here is what I THINK I know: - In MariaDB 5.5, we must fsync our recovery log on handlerton->prepare and handlerton->commit - If we want to ensure that the order we commit transactions is the same order that they appear committed in the binary log, then we should perform our commit in two phases, commit_ordered and commit, where commit_ordered is serialized under a global mutex that ensures the correct order - InnoDB must do this for hot backup to work Here is my big question: given TokuDB is not designed to work with InnoDB's hot backup solution, is there ANY reason why we should care about the commit order of our transactions? Are there any performance reasons related to group commit? >From everything I read, I think the answer is no, but I would appreciate confirmation. I think there are no performance gains to be made by implementing commit_ordered, and given we fsync on commit, there should be no issues with syncing our engine up with the binary log after a crash. Also, I assume the fsync after commit is necessary. Only in 10.0 will some new functionality be available that allows us to not fsync on commit. Is my understanding correct? Thanks -Zardosht

2 7

Re: [Maria-developers] Rev 3663: MDEV-3819 missing constraints for spatial column types
by Sergei Golubchik 20 Feb '13

20 Feb '13

Hi, Holyfoot! On Feb 20, holyfoot(a)askmonty.org wrote: > revno: 3663 > revision-id: holyfoot(a)askmonty.org-20130220195237-99gp9p29xemltqcm > parent: vvaintroub@pcbsd-20130219224652-t84v8wepdqvhxfwb > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-3819 > timestamp: Wed 2013-02-20 23:52:37 +0400 > message: > MDEV-3819 missing constraints for spatial column types. > Checks added to return and error when inappropriate > geometry type is stored in a field. > === modified file 'mysql-test/r/gis.result' > --- a/mysql-test/r/gis.result 2012-09-05 21:14:33 +0000 > +++ b/mysql-test/r/gis.result 2013-02-20 19:52:37 +0000 > @@ -1491,4 +1491,11 @@ SELECT 1 FROM g1 WHERE a >= ANY > (SELECT 1 FROM g1 WHERE a = geomfromtext('') OR a) ; > 1 > DROP TABLE g1; > +# > +# MDEV-3819 missing constraints for spatial column types > +# > +create table t1 (pt point); > +insert into t1 values(Geomfromtext('POLYGON((1 1, 2 2, 2 1, 1 1))')); > +ERROR HY000: Incorrect POLYGON value: 'POINT' I'm sorry, but you got it backwards :) The value above is POLYGON. The type is POINT. The error message should be ERROR HY000: Incorrect POINT value: 'POLYGON' Regards, Sergei

2 1

Re: [Maria-developers] Rev 3663: MDEV-3819 missing constraints for spatial column types
by Sergei Golubchik 20 Feb '13

20 Feb '13

Hi, Holyfoot! On Feb 20, holyfoot(a)askmonty.org wrote: > revno: 3663 > revision-id: holyfoot(a)askmonty.org-20130220172419-j5sad8p7t3191kii > parent: vvaintroub@pcbsd-20130219224652-t84v8wepdqvhxfwb > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-3819 > timestamp: Wed 2013-02-20 21:24:19 +0400 > message: > MDEV-3819 missing constraints for spatial column types. > Checks added to return and error when inappropriate > geometry type is stored in a field. > > === modified file 'sql/field.cc' > --- a/sql/field.cc 2013-01-28 12:36:05 +0000 > +++ b/sql/field.cc 2013-02-20 17:24:19 +0000 > @@ -7580,6 +7580,12 @@ int Field_geom::store(const char *from, > if (wkb_type < (uint32) Geometry::wkb_point || > wkb_type > (uint32) Geometry::wkb_last) > goto err; > + > + if (geom_type != Field::GEOM_GEOMETRY && > + geom_type != Field::GEOM_GEOMETRYCOLLECTION && > + (uint32) geom_type != wkb_type) > + goto err_wrong_type; why goto err_wrong_type? there's no common cleanup or any common code at all at the end, you can put it right here in the if(). > + > Field_blob::store_length(length); > if (table->copy_blobs || length <= MAX_FIELD_WIDTH) > { // Must make a copy > @@ -7595,6 +7601,12 @@ int Field_geom::store(const char *from, > my_message(ER_CANT_CREATE_GEOMETRY_OBJECT, > ER(ER_CANT_CREATE_GEOMETRY_OBJECT), MYF(0)); > return -1; > + > +err_wrong_type: > + bzero(ptr, Field_blob::pack_length()); > + my_message(ER_WRONG_GEOMETRY_TYPE, > + ER(ER_WRONG_GEOMETRY_TYPE), MYF(0)); > + return -1; > } > > #endif /*HAVE_SPATIAL*/ > > === modified file 'sql/share/errmsg-utf8.txt' > --- a/sql/share/errmsg-utf8.txt 2013-02-08 21:24:06 +0000 > +++ b/sql/share/errmsg-utf8.txt 2013-02-20 17:24:19 +0000 > @@ -6588,3 +6588,5 @@ ER_QUERY_EXCEEDED_ROWS_EXAMINED_LIMIT > ER_NO_SUCH_TABLE_IN_ENGINE 42S02 > eng "Table '%-.192s.%-.192s' doesn't exist in engine" > swe "Det finns ingen tabell som heter '%-.192s.%-.192s' i handlern" > +ER_WRONG_GEOMETRY_TYPE > + eng "Unsuitable geometry type for the field" Ouch, is that really needed? Can you use ER_WRONG_VALUE instead? Like Incorrect POINT value: 'POLYGON((1 1, 2 2, 2 1, 1 1))' Regards, Sergei

1 0

[Maria-developers] Determining to which project a patch should be sent.
by Christian Convey 20 Feb '13

20 Feb '13

Hi guys, As I work through the Coverity Scan results of MariaDB's trunk, I find myself having to research what some functions do, and the meanings of their parameters and return values. Rather than just recording what I learn on a piece of paper, I thought it might be nice to write Doxygen comments for some of those functions / structs / etc. That way, perhaps other persons trying to learn the code base could benefit. Here's the problem. Based on Monty's blog posting about MariaDB 10 vs. MySQL 5.6 ( http://blog.mariadb.org/mariadb-10-0-and-mysql-5-6/ ), it's not obvious to me which files / functions / etc. in MariaDB have been forked from MariaDB, vs. which ones will be replaced with the corresponding MySQL code when the next MySQL release comes out. This means that when I write Doxygen comments for a given file / function /struct / etc., I don't know whether to submit that comment patch to the MariaDB project or to the MySQL project. Does anyone know I I can figure that out? Thanks, Christian

3 5

[Maria-developers] binlog event of COMMIT statement
by nanyi607rao 20 Feb '13

20 Feb '13

I am little confused about binlog event of COMMIT statement, In most of time, a COMMIT statement corresponds a XID_event in the binlog, but sometimes is a Query_event. how that happened ? or can I do any operations to make a COMMIT statement correspond a Query_event certainly in the binlog. Thankes, Longhui 2013-02-20 nanyi607rao

2 1

[Maria-developers] my_hash_sort_bin
by MARK CALLAGHAN 20 Feb '13

20 Feb '13

Hello MariaDB, While working with Dmitry Lenev to understand why MySQL 5.6 was slower than 5.1 on one benchmark ( https://www.facebook.com/notes/mysql-at-facebook/my-mysql-is-faster-than-yo…) we realized that the hash function used in my_hash_sort_bin is lousy for this input: test.sbest1, test.sbtest2, ..., test.sbtest10. The problem is made worse when a small number of hash buckets is used because the hash function output doesn't do the right thing for the least significant bits so that all 10 inputs map to the same hash bucket. More details are at http://bugs.mysql.com/bug.php?id=66473 The InnoDB hash function is much better. Details for that and a test program are in the bug report. Does anyone remember why this hash function was chosen? strings/ctype-bin.c doesn't have any comments explaining why this hash function was selected. This is another peeve for me. Critical code like this should be explained if we expect anyone new to begin working on this code. I haven't done a formal test of the hash function, and http://burtleburtle.net/bob/hash/hashfaq.html would be a good reference for that. But I think it is very likely that my assertion that this hash function is lousy holds in general, rather than is limited to this input. And given the large number of machines that run MySQL, MariaDB and Percona Server (and the FB patch) around the world I suspect that we should figure this out. -- Mark Callaghan mdcallag(a)gmail.com

2 1

[Maria-developers] implementing multi range read at the storage engine in MariaDB 5.5
by Zardosht Kasheff 19 Feb '13

19 Feb '13

Hello all, Is there anything to implementing multi range read for storage engines? Or is there a default implementation that is likely good enough. Also, is there anything one can read to understand how the feature works and its benefits? Thanks -Zardosht

3 3

[Maria-developers] Using C++ features in MariaDB
by Christian Convey 19 Feb '13

19 Feb '13

I just read in Pachev's "MySQL Internals" book that C++ STL and exceptions aren't allowed in the MySQL code. Are those restrictions also in effect for MariaDB? If so, can anyone explain the reason for them? Thanks, Christian

2 8