- developers - lists.mariadb.org

[Maria-developers] MYSQL_TYPE_DECIMAL type
by Zardosht Kasheff 08 May '13

08 May '13

Hello all, Under what circumstances can a table be created with MYSQL_TYPE_DECIMAL as being one of the columns? I thought MYSQL_TYPE_DECIMAL was deprecated pre 5.1. I thought all new tables use MYSQL_TYPE_NEWDECIMAL. We have a user reporting a table he wants to alter has that type. However, when I create that table, I don't get that type. As an aside, we don't support that type, mainly because I thought it was impossible to have a table created with it (I am apparently wrong). Is there a way to ensure that tables undergoing an alter convert that column to MYSQL_TYPE_NEWDECIMAL? Thanks -Zardosht

3 3

[Maria-developers] is this a bug?
by jhx1008 08 May '13

08 May '13

hi all: I have a problem about the type cast when I have read the source of Maria & MySQL I notice that when cast from string into int, Maria & MySQL do it like the C function atoi code: for (ul= 0 ; str < end9 && (ch= (uchar) (*str - '0')) < 10; str++) { ul= ul * 10 + ch; } but cast from hex into int, the code is: code: char *end=(char*) str_value.ptr()+str_value.length(), *ptr=end-min(str_value.length(),sizeof(longlong)); ulonglong value=0; for (; ptr != end ; ptr++) value=(value << 8)+ (ulonglong) (uchar) *ptr; so I do the test blew: create table t(id int auto_increment primary key, a int)engine=innodb; insert into t(a) values('1'); insert into t(a) values(0x31); everything is ok, I get the result: mysql> select * from t; +----+------+ | id | a | +----+------+ | 1 | 1 | | 2 | 49 | +----+------+ the value 0x31 is the ascii of the string '1', but we got the different result after inserting maybe it's not a problem, but in the replication environment, it maybe cause the data of slave not the same as master In the master, when we set the connection characterset into multi-bytes characterset and this characterset may escape with backslash is dangerous (like gbk, cp932) and then we use the prepared statement to do the insert, the string value in the insert must be cast into hex before write into the binlog, so we do the insert(insert into t(a) values('1')) on the master, but in the slave it does the another(insert into t(a) values(0x31)) , the data is not the same. how to reappear: master(binlog format=statement): create table t(id int auto_increment primay key, a int) engine=innodb; set names gbk; prepare stmt from 'insert into t(a) values(?)'; set @a='1'; execute stmt using @a; the result in master is: mysql> select * from t; +----+------+ | id | a | +----+------+ | 1 | 1 | +----+------+ and result in slave is: mysql> select * from t; +----+------+ | id | a | +----+------+ | 1 | 49 | +----+------+ I test the newest release version mariadb-10.0.2 and MySQL-5.6.10, the problem is still exist, is this a bug? 2013-04-28 jhx1008 @netease

4 7

[Maria-developers] MariaDB allows for slave to connect with non-existent GTID
by Pavel Ivanov 07 May '13

07 May '13

Kristian, I've realized that the way slaves are processed now on the master allows them to connect even if they request non-existent GTID. Is it "works as intended" and will be different in the "strict mode" or you didn't want for such things to happen even in non-strict mode? I've attached a test reproducing the problem. It sets up replication 1->2->3, executes transaction on 1, executes transaction on 2, disconnects 3, executes one more transaction on 1, fails over to 2, executes one more transaction on 2. Then when it tries to connect 3 to 1 it should fail because 1 doesn't have the last transaction that 3 has. I agree that this scenario is artificial, but in reality scenario can be e.g. like this: 2 is slave of 1, then it gets disconnected and executes one extra transaction, then backup is taken from 2, then 2 gets restarted and restored to the state of 1, then failover happens and 2 becomes master, then 3 restores from the backup taken earlier from 2 and if all this time 1 and then 2 as masters executed some transactions 3 will be able to connect to 2 even though its last transaction doesn't exist on 2... Pavel

2 3

[Maria-developers] Missing locking around THD::set_db() ?
by Kristian Nielsen 07 May '13

07 May '13

Hi, I was looking at a Valgrind warning in Buildbot (appended below). What happens seems to be this: Thread 1 is running SHOW PROCESSLIST, it grabs the pointer THD::db to the current database of thread 2. Thread 2 then does THD::set_db(), freeing the old THD::db pointer and allocating a new one with the new data. Thread 1 then resumes, doing strdup() of the _old_, now invalid, THD::db pointer, which reads garbage data (or could even segfault if we get really unlucky). This seems like a genuine bug. I see absolutely no locking protecting against this race :-( Any suggestions for how to deal with this? The only locking I see in mysqld_list_processes() is holding LOCK_thread_count, but taking that for every THD::set_db() sounds quite bad for scalability (for example, set_db() is run by every query replicated by a slave thread). Should we use LOCK_thd_data also for THD::db ? Or maybe we could have a fixed buffer in THD for the db? Seems we would need 193 bytes. Then SHOW PROCESSLIST could sometimes show a random mix of old and new db name if we race, but at least we would not read invalid memory or crash due to mummap() ... Any better ideas? - Kristian. ----------------------------------------------------------------------- Original valgrind warning, for reference: rpl.rpl_stop_slave 'mix,xtradb' w5 [ fail ] Found warnings/errors in server log file! Test ended at 2013-04-22 22:05:12 line ==9897== Thread 20: ==9897== Invalid read of size 1 ==9897== at 0x4C2826B: memcpy (mc_replace_strmem.c:878) ==9897== by 0xBAF9E8: strmake_root (my_alloc.c:424) ==9897== by 0x63C74E: mysqld_list_processes(THD*, char const*, bool) (sql_class.h:771) ==9897== by 0x5C8574: mysql_execute_command(THD*) (sql_parse.cc:3149) ==9897== by 0x5CC844: mysql_parse(THD*, char*, unsigned int, Parser_state*) (sql_parse.cc:5759) ==9897== by 0x5CDDC9: dispatch_command(enum_server_command, THD*, char*, unsigned int) (sql_parse.cc:1068) ==9897== by 0x5CE4BD: do_command(THD*) (sql_parse.cc:794) ==9897== by 0x6A4E23: do_handle_one_connection(THD*) (sql_connect.cc:1266) ==9897== by 0x6A4F23: handle_one_connection (sql_connect.cc:1181) ==9897== by 0x8F0027: pfs_spawn_thread (pfs.cc:1015) ==9897== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so) ==9897== by 0x62F713C: clone (in /lib64/libc-2.9.so) ==9897== Address 0x1a06a973 is 3 bytes inside a block of size 5 free'd ==9897== at 0x4C257D8: free (vg_replace_malloc.c:446) ==9897== by 0xBB96BB: my_free (my_malloc.c:115) ==9897== by 0x838C86: Query_log_event::do_apply_event(Relay_log_info const*, char const*, unsigned int) (sql_class.h:2846) ==9897== by 0x53904C: apply_event_and_update_pos(Log_event*, THD*, Relay_log_info*) (log_event.h:1230) ==9897== by 0x5446DD: exec_relay_log_event(THD*, Relay_log_info*) (slave.cc:2766) ==9897== by 0x545BD9: handle_slave_sql (slave.cc:3627) ==9897== by 0x8F0027: pfs_spawn_thread (pfs.cc:1015) ==9897== by 0x4E3506F: start_thread (in /lib64/libpthread-2.9.so) ==9897== by 0x62F713C: clone (in /lib64/libc-2.9.so)

4 4

Re: [Maria-developers] [Gsoc] Regex enhancements Project
by Sergei Golubchik 04 May '13

04 May '13

Hi, Sudheera! On Apr 19, Sudheera Palihakkara wrote: > Hi, > I went through other threads on this topic. In one thread you mentioned to > choose a suitable regex library. > > *( Preliminary research - only about chosing a regex library to use in > MariaDB. You should be able to explain why we should use this library and > not some other one.) > > * > What do you mean by "choosing"? don't we have to enhance the exiting regex > library? Or choose from exiting already implemented libraries which are > free to use? sorry if it's a stupid question, but I'm confused. :O Enhancing our old regex library to support all modern features and multiple charsets is complex and bug-prone work. I don't see why we should bother doing it, when there are plenty of regex libraries available. There's PHP's mb_regex, there's prce, and many others too. We'd better just pick one that works better for MariaDB, and put it instead of Henry Spencer's library. Regards, Sergei P.S. Please, don't reply to me only, use reply-to-all, so that your mails appear on the mailing list.

3 9

[Maria-developers] Fwd: MariaDB release numbering
by Jorge Manuel B. S. Vicetto 03 May '13

03 May '13

Hi. I've emailed Kristian about this subject and he suggested I sent this to your mailing list to get a more complete picture. On our work packaging MariaDB for Gentoo, me and Robin need to decide how to deal with the packaging of MySQL vs MariaDB and to that it would be really helpful to have an idea of how you plan to number your future releases. AFAIK, currently we can compare MySQL vs MariaDB as: MySQL MariaDB 5.1 5.1 / 5.2 / 5.3 5.5 5.5 (including MariaDB features from 5.2/5.3) 5.6 10.0 (based on MySQL 5.5 with backports from MySQL 5.6 and features from previous MariaDB versions) 5.7 ??? The first question for us is what version number will you use for a newer version based on MySQL-5.7. Another question is if you plan to port all your work to the 5.7 codebase or if you'll keep working on the current 10.0 codebase and do backports from 5.7 (like you did for MySQL 5.6). A second question is whether you still claim binary compatibility with MySQL[1] and how would you compare the latest versions of MariaDB and MySQL (10.0 vs 5.6, 5.7). [1] - https://kb.askmonty.org/en/mariadb-versus-mysql-compatibility/ Any info you can share on the release versioning plans would be really helpful. If this is still too early for any definitions or comments, is there any way we can follow or learn about such decisions? Thank you and regards, Jorge Manuel B. S. Vicetto Gentoo Developer

2 1

[Maria-developers] Forked mytop - conflicts, issues
by Honza Horak 03 May '13

03 May '13

Hi guys, MariaDB forked mytop utility source some time back, but it causes some issues for us in Fedora for example (and similarly in other distributions I guess) -- particularly the MariaDB's binary mytop conflicts with the same utility from separate package mytop. So, I'd like to take a look at possible solutions. Since there was a small commit in mytop upstream few weeks back, it doesn't really look like totally dead upstream. So the ideal solution from my POV would be including enhancements that MariaDB did to mytop back to upstream and not including mytop utility in MariaDB any more. Would something like that be possible from the perspective of MariaDB? Cheers, Honza

4 4

[Maria-developers] xa transaction cause replication broken
by jhx1008 02 May '13

02 May '13

hello I have another problem witch seems like a bug(Server version: 5.5.5-10.0.2-MariaDB-log MariaDB Server). the problem is about the replication for the xa transactions when the master crashed and then restarted. I know when we do a transaction, the queries will be stored in the binlog cache, after commit, flush the binlog cache into the binlog file, any normal un-committed transactions will be rollbacked when the server crashed then restarted, but the prepared xa transactions are not. Prepared xa transactions can be recovered use the command 'xa recover', then committed use 'xa commit xid', but the binlog cache is empty when the master restart, so if we do the 'xa commit xid', nothing to be recorded into the binlog files, the replication will be broken. test: master mysql> create table t(id int auto_increment primary key, a int) engine=innodb; mysql> xa start '111'; mysql> insert into t(a) values(1); mysql> xa end '111'; mysql> xa prepare '111'; kill -9 master_pid restart the master mysql> xa recover; +----------+--------------+--------------+------+ | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+------+ | 1 | 3 | 0 | 111 | +----------+--------------+--------------+------+ mysql> xa commit '111'; mysql> select * from t; Empty set (0.00 sec) why? I did the xa commit '111', but no result return, maybe another bug? do the test continue mysql> xa start '222'; mysql> insert into t(a) values(2); mysql> xa end '222'; mysql> prepare '222'; mysql> xa commit '111'; mysql> select * from t; +----+------+ | id | a | +----+------+ | 1 | 1 | | 2 | 2 | +----+------+ value(1,1) return at this time, why? what's hanppen on the slave? mysql> select * from t; +----+------+ | id | a | +----+------+ | 2 | 2 | +----+------+ the replication is broken now!! by the way, when the xa transactions preapred, if the client exit, the transactions will be rollbacked in the THD::cleanup function, maybe the server rollback all the xa prepared transcations when restart is a good method? 2013-05-02 jhx1008 @netease

2 2

[Maria-developers] GTIDs, events sequence and alternate futures
by Pavel Ivanov 01 May '13

01 May '13

Kristian, I can't find the answer to my questions in the code and don't know if there's some documentation I can use (is there such thing?), so I'm writing my questions here. As I understand GTID is constructed as <domain id>-<server id>-<sequence number>. Is it guaranteed that sequence numbers are always increasing inside the domain id? So let's say two servers have GTID 0-1-100 and if they have alternate futures then one server will have GTIDs 0-1-101, 0-1-102 and so on, while second server will have 0-2-101, 0-2-102 etc. Is that correct? BTW, where in the code is sequence number increased exactly? Thank you, Pavel

2 4

Re: [Maria-developers] Installing jemalloc on build VMs
by Kristian Nielsen 26 Apr '13

26 Apr '13

Daniel Bartholomew <dbart(a)mariadb.org> writes: > I'm getting ready to install jemalloc on the buildslaves for TODO-459 - > https://mariadb.atlassian.net/browse/TODO-459 , and wanted to know if > there was a preferred way to do it. Since we want to use a specific > version of jemalloc (3.1.0), I figured I would build from source on all > of the build machines. Has this been thought through properly with respect to packaging? My guess is it has not. For .debs, which are what I know about, it is generally expected that one can rebuild from `apt-get source mariadb-server`. This requires proper build dependencies. It doesn't work to install random stuff on random machines. It does not appear that jemalloc 3.1 is available on most .deb distros we support. Wheezy seems to have 3.0.0. It is said that tokutek "requires" jemalloc - maybe it would be better to fix tokutek to work with standard libraries? The proper way to produce .debs with custom jemalloc requires creating new custom packages for libjemalloc and including them in our repos. - Kristian.

8 11