- developers - lists.mariadb.org

Re: [Maria-developers] Getting community to write missing test cases
by Kristian Nielsen 21 May '13

21 May '13

Elena Stepanova <elenst(a)montyprogram.com> writes: > If we start doing it, Oracle will soon realize that this activity is > based at least as much on commit comments as on the code. As a result, > they will probably start making much vaguer comments than they do now, > which in turn might make merge and related activities even more > complicated than they are now. I wouldn't worry about that. First, I do not believe day-to-day developers spend any effort to actively conceal things for outside developers. The ban on bug test cases seems to have come from a generic security team mandate, which has roots some years back where Oracle were hit quite hard with countless vulnerabilities after their "can't break it - can't break in" campain. Second, even if they did, anything that makes Oracle close down more benefits the adoption of the forks. But most importantly, we must not get into the mentality that we let what Oracle might or might not do influence how we work. We need to go in whatever direction we believe is best for the project. Oracle has made it plain that they do not want to participate in the community, and we should just ignore them until such time as they might decide otherwise. - Kristian.

1 0

[Maria-developers] Feature Request - Working auto_increment on BlackHole Engine
by Gordan Bobic 20 May '13

20 May '13

How difficult would be be to implement working auto-increment functionality on the BlackHole engine? This would be really useful for what I'm trying to do at the moment. Since it is not available and there are no sequences in MariaDB and MySQL, I have to resort to a hack such as a single-int-field table doing the auto-increment, and an insert trigger on the blackhole table to insert a null into the auto-increment tracking table, get LAST_INSERT_ID() to set the value in the auto-increment table, and then delete the record. Even with InnoDB log files and tablespace on tmpfs this makes the performance nosedive by a factor of 4 if the trigger doesn't bother cleaning up the auto-increment table, and a factor of 13 if it deletes the record immediately after inserting it. The actual times I tested with 24 inserter threads on a 24-thread server are 8m vs. 30m vs. 105m, i.e. a massive drop. Is there an better place than this list for a feature request? Gordan

3 6

[Maria-developers] Ogg vorbis based table
by Roberto Spadim 18 May '13

18 May '13

Hi guys, i was listening some musics, and i had a idea... let's me explain Some systems are based in time and value, an example of scada systems. In this kind of system we have an 'channel' (like right or left sound channel) a timestamp and a value, normally a table like CREATE TABLE history( Channel int not null default 0, Datetimestamp decimal(22,7) not null default 0, Value decimal(22,5) default NULL, Primary key (channel,datetimestamp) ) Some explanations and features that scada systems use... Value can be NULL, in this case we could think like MUTE function on audio files Datetime normally are gmt, or unixtimestamp values with microsecond precision, they could be fixed interval or not, example... 1 2 3 4 5... (q second interval), in audio it's fixed sample rate, or not fixed interval (variable sample rate), like 1 3 4 9... Well what i'm thinking... today mariadb 10.0.2 started the CONNECT table type (please correct me if i'm wrong), that can 'connect' to a xml,txt,csv and others kinds of files to read and write it's values... Could we implement mp3, wave, ogg vorbis, file type type? This is a really nice 'table compression' for scada systems, and allow a new era of table type, think about... Select datetimestamp from someaudiofile where someniceaudiofunction()>1 In this example we could check date time where some scada value get over a fixed level, or where a frequency get higher and start a alarm condition, it could be used to get more information using statistics functions... i'm talking now about a new table type and new functions... but thats the idea... Anyone intested in this? About table compression think about compressing tax values in nasdaq for example, and execute a statistic analyse with this information... Well just some uses... Thanks for the space to show my idea and your time to read it Maybe a video table in future, or image based... just to use jpeg compreesion (x,y,color values) and others kinds of files... Bye

1 0

[Maria-developers] Empty_queries vs Com_empty_queries
by Ian Gilfillan 18 May '13

18 May '13

I'm documenting the status variables at the moment, and have a question about Empty_queries vs Com_empty_queries. Com_empty_queries is not incremented when an empty result is returned, and appears to be incremented only when an empty query is sent to the server, eg: mysql --comments -e '-- sql comment' Empty_queries appears to match the empty queries returned with SHOW USER_STATISTICS. It increments each time a query is performed that returns an empty result. Currently the documentation on the user statistics page at https://kb.askmonty.org/en/user-statistics/ says that EMPTY_QUERIES (and therefore the Empty_queries status variable) is "The number of times this user's connections sent empty queries to the server", which would describe Com_empty_queries rather than Empty_queries, and would need to be corrected. The documentation on https://kb.askmonty.org/en/server-status-variables/ is what I've just written based on the above. Have I understood this correctly, or is there something else to it? thanks, ian

3 2

[Maria-developers] To Sergei:
by Samarth Mathur 16 May '13

16 May '13

Hi Sergei.. just a few questions. Hope not to bother too much! does the .so file of two_questions exist in the mariadb 10.0.2 source code or was that just an example? Also, if I'm looking to implement pluggable authentication for LDAP, does the version of mariadb, i'm doing this on matter? if it does, which version would you recommend? I'm currently on v10.0.2.. What is the advantage of going for a pluggable authentication over say a module made for the PAM plugin in mariadb? Regards Sam

3 6

Re: [Maria-developers] Feature Request - Working auto_inc rement on BlackHole Engine
by Gordan Bobic 15 May '13

15 May '13

On 05/15/2013 11:27 PM, Jocelyn Fournier wrote: > Hi Gordan, > > > Le 15/05/13 22:18, Gordan Bobic a écrit : >> On 05/15/2013 09:06 PM, Michael Widenius wrote: >>> >>> Hi! >>> >>>>>>>> "Gordan" == Gordan Bobic <gordan(a)bobich.net> writes: >>> >>> Gordan> How difficult would be be to implement working >>> Gordan> auto-increment functionality on the BlackHole engine? >>> >>> Gordan> This would be really useful for what I'm trying to do at >>> Gordan> the moment. Since it is not available and there are no >>> Gordan> sequences in MariaDB and MySQL, I have to resort to a >>> Gordan> hack such as a single-int-field table doing the >>> Gordan> auto-increment, and an insert trigger on the blackhole >>> Gordan> table to insert a null into the auto-increment >>> Gordan> tracking table, get LAST_INSERT_ID() to set the >>> Gordan> value in the auto-increment table, and then delete >>> Gordan> the record. >>> >>> What problem is that you wanted to solve? >>> Normally blackhole is used just for creating a slave of a slave that >>> doesn't have to hold any data (only the logs). >> >> The problem is a huge volume logging application that needs to have >> uniquely enumerated records for auditing purposes. > > Have you tried TokuDB engine ? It isn't suitable for what I am doing in this case - note that the blackhole engine in this case suits all of my requirements except for the working auto_increment functionality. I don't need to store the data on these nodes, merely binlog it up for further processing downstream. Gordan

1 0

[Maria-developers] MariaDB GTID first impression
by Giuseppe Maxia 15 May '13

15 May '13

Kristian, Thanks for the docs. It's a very good start. Compared to MySQL 5.6, GTID in MariaDB has some advantages: it is enabled by default and it is easy to read. There are a few items, though, that should need some more thought: 1) rpl_slave_state is probably ill-named. In this architecture, it is only written by the slaves, and thus the name matches, but I wonder if the master should write this table (or a similar one) to keep track of its progress in the binary log. Rationale: all the info related to replication should be in tables and easy to query. 2) rpl_slave_state does not have enough metadata. What is missing here, and would be extremely useful, is the corresponding binlog+position for each GTID, a timestamp of when the transaction was saved to the binary log, and the timestamp of when it was applied. (The host name of the origin would also be useful). Also very important (when you will implement parallel replication) is a shard identifier. 3) Multiple domains do not integrate well with GTID. In multi-source replication, we use "connection names", but for GTID we use "domain numbers". They do not play well together : there is no correspondence between the gtid_domain_id and the connection name, and a "SHOW ALL SLAVES STATUS" lists all the GTID for every connection. For example: mysql -e 'show all slaves status\G' |grep 'Connection_name\|Running\|Master_Host\|Master_Port\|Gtid_Pos\|Master_Log' Connection_name: Bear Master_Host: 127.0.0.1 Master_Port: 8203 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 1020 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 1020 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Wolf Master_Host: 127.0.0.1 Master_Port: 8204 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 896 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 896 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Fox Master_Host: 127.0.0.1 Master_Port: 8205 Master_Log_File: mysql-bin.000002 Read_Master_Log_Pos: 365 Relay_Master_Log_File: mysql-bin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 365 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Connection_name: Deer Master_Host: 127.0.0.1 Master_Port: 8206 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 1144 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes Exec_Master_Log_Pos: 1144 Gtid_Pos: 100-101-21,400-104-23,200-102-8,300-103-12,500-105-20 Which connection is running which gtid number? Not easy to tell, as the correspondence between domain and connections is only in the DBA's head. 4) gtid_pos is text that includes all sequences from all domains. The docs say that I can modify it if needed, but in a case like the one above, modifying this string can be very error prone. For example, if server_ids are assigned using inet_aton(@IP), you could have a gtid_pos like this '1001-170062692-230000,1002-170062593-12893445,1003-170062700-672009,1003-170062699-700002' Instead of editing a string, and risk breaking replication in all domains, I would expect the availability of commands like: CHANGE GTID for domain 'Wolf' set gtid_pos=1900 That's it for now. Hope there is still room for improvements. Cheers Giuseppe

3 16

Re: [Maria-developers] MariaDB build logs
by Kristian Nielsen 14 May '13

14 May '13

Marcin Kulisz <debian(a)kulisz.net> writes: > as promised I'm attaching build log for maria DB, it's much smaller then > anticipated. Thanks! > From what I can tell it was just one test which failed and rendered whole build as a > failure. > My build env is based on cowbuilder on fully patched SID chroot. Ah, I see what is going on: > plugins.unix_socket [ fail ] > Test ended at 2013-05-11 00:12:52 > --- /tmp/buildd/mariadb-5.5-5.5.29/builddir/mysql-test/suite/plugins/r/unix_socket.result 2013-05-10 21:49:20.510929790 +0000 > +++ /tmp/buildd/mariadb-5.5-5.5.29/builddir/mysql-test/suite/plugins/r/unix_socket.reject 2013-05-11 00:12:52.562350485 +0000 > @@ -8,7 +8,7 @@ > # > select user(), current_user(), database(); > user() current_user() database() > -USER@localhost USER@% test > +USER@localhost USER@localhost test > # > # name does not match = failure > # Right, so the problem is that this test is poorly written. Its output depends on the name of unix username of the account running the test! I am guessing that in your case, you build as user root. Since the MariaDB server running in the test happens to also have a (database) account named root, we get an authenticated user USER@localhost instead of an anonymous user. I have now pushed a fix for this problem to the MariaDB tree: http://lists.askmonty.org/pipermail/commits/2013-May/004715.html So this fix will appear in MariaDB 5.5.31 or possibly 5.5.32 (not sure if it made it in 5.5.31, which I think is due for release). Until that fix propagates to the MariaDB packaging, some options for a work-around are: - Run the build as a non-root user, with fakeroot. - Skip the test suite during build (DEB_BUILD_OPTIONS=nocheck) (this will also greatly speed up the build). - Apply the linked patch manually Hope this helps, - Kristian.

1 0

Re: [Maria-developers] Forked mytop - conflicts, issues | fullqueries overflow bug patch
by Jean Weisbuch 14 May '13

14 May '13

Hi, I attached to this message a patch to fix the overflow when fullqueries is activated and full queries are taking more than a line that might be resulting in a page overflow (the informations shown on mytop will exceed the terminal height). As for the latest commit upstream (21, mar 2013 https://github.com/jzawodn/mytop/commit/437f2ef8d3fce02eafe935ddbf860d1dfbc…) its only a small fix that seems to already have been fixed on the MariaDB version. Regards.

1 0

Re: [Maria-developers] [Commits] Rev 3654: MDEV-4290: in file:///home/bell/maria/bzr/work-maria-5.3-MDEV-4290/
by Sergei Golubchik 13 May '13

13 May '13

Hi, Sanja! On May 03, sanja(a)askmonty.org wrote: > revno: 3654 > revision-id: sanja(a)askmonty.org-20130503130713-0n5lgrniay7n3jua > parent: igor(a)askmonty.org-20130430033140-qhx9wsgc5w2dx14r > committer: sanja(a)askmonty.org > branch nick: work-maria-5.3-MDEV-4290 > timestamp: Fri 2013-05-03 16:07:13 +0300 > message: > MDEV-4290: > Fix agregate function resolution in derived tables (no name > resolution over a derived table border) ok to push Regards, Sergei

1 0