January 2011 - developers - lists.mariadb.org

[Maria-developers] test please ignore
by Vladislav Vaintroub 14 Jan '11

14 Jan '11

Checking mailing list access

1 0

Re: [Maria-developers] [Commits] Rev 2876: Fixed LP bug #698882. in file:///home/igor/maria/maria-5.3-bugs/
by Oleksandr Byelkin 14 Jan '11

14 Jan '11

Hi! On 13.01.2011 01:11, Igor Babaev wrote: > At file:///home/igor/maria/maria-5.3-bugs/ > > ------------------------------------------------------------ > revno: 2876 > revision-id: igor(a)askmonty.org-20110112231059-prhv2vncj6y2cizn > parent: igor(a)askmonty.org-20110105230330-2nzlm8641wcrwzio > committer: Igor Babaev<igor(a)askmonty.org> > branch nick: maria-5.3-bugs > timestamp: Wed 2011-01-12 15:10:59 -0800 > message: > Fixed LP bug #698882. > Made sure that the optimal fields are used by TABLE_REF objects > when building index access keys to joined tables. > Fixed a bug in the template function that sorts the elements of > a list using the bubble sort algorithm. The bug caused poor > performance of the function. Also added an optimization that > skips comparison with the most heavy elements that has been > already properly placed in the list. > Made the comparison of the fields belonging to the same Item_equal > more granular: fields belonging to the same table are also ordered > according to some rules. The patch as OK. But I'd prefer to have comment that the lists are mostly short and because of this used bubble sort algorithm (or you could use more detailed explanation from your letter to me). Also in big 'if (!cmp)' used tabulation (it is visible if you check diff where layout looks not correct, but it is correct in the result file), if it is not difficult it would be better to remove them. [skip]

1 0

[Maria-developers] WL#174 New (by Monty): Safety improvements for HANDLER commands
by worklog-noreply＠askmonty.org 14 Jan '11

14 Jan '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Safety improvements for HANDLER commands CREATION DATE..: Fri, 14 Jan 2011, 12:43 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 174 (http://askmonty.org/worklog/?tid=174) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 20 (hours remain) ORIG. ESTIMATE.: 20 PROGRESS NOTES: DESCRIPTION: There is some known problems with HANDLER implementation in some storage engines, that could potentially cause crashes that should be fixed ASAP. We should also do some trivial fixes to ensure that one gets Error 1020 (ER_CHECKREAD) Record has changed since last read in table '...' in so few cases as possible. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] Documentation for Percona patch for row-based replication of pk-less tables
by Kristian Nielsen 13 Jan '11

13 Jan '11

Hi Daniel, I merged the Percona patch row_based_replication_without_primary_key.patch into 5.2-percona. This will later be merged into MariaDB 5.3. Here is some documentation, I was not sure where to put it, so hopefully you can help. The patch adds a new feature (performance improvement), and also fixes a bug. Incidentally, do we have a list of all bugs fixed in MariaDB over MySQL? I think that would be quite useful, even if it might get a bit out of date as MySQL also fixes some bugs. I suppose it could mostly be compiled from your release notes. This would also provide motivation for developers to actually make a proper bug report on issues fixed and proper commit messages etc :-) Anyway, just a suggestion. - Kristian. ----------------------------------------------------------------------- Row-based replication of tables with no primary key. MariaDB improves on row-based replication of tables which have no primary key but do have some other index. This is based in part on the original Percona patch "row_based_replication_without_primary_key.patch", with some additional fixes and enhancements. When row-based replication is used with UPDATE or DELETE, the slave needs to locate each replicated row based on the value in columns. If the table contains at least one index, an index lookup will be used (otherwise a table scan is needed for each row, which is extremely inefficient for all but the smallest table and generally to be avoided). >From MariaDB 5.3, the slave will try to choose a good index among any available: - The primary key is used, if there is one. - Else, the first unique index without NULL-able columns is used, if there is one. - Else, a choice is made among any normal indexes on the table (eg. a FULLTEXT index is not considered). The choice of which of several non-unique indexes to use is based on the cardinality of indexes; the one that is most selective (has the smallest average number of rows per distinct tuple of column values) is prefered. Note that for this choice to be effective, it is for most storage engines (like MyISAM, InnoDB) necessary to make sure ANALYZE TABLE has been run on the slave, otherwise statistics about index cardinality will not be available. In the absense of index cardinality, the first unique index will be chosen, if any, else the first non-unique index. Prior to MariaDB 5.3, the slave would always choose the first index without considering cardinality. The slave could even choose an unusable index (like FULLTEXT) if no other index was available (Bug #58997), causing row-based replication to break in this case; this is also fixed in MariaDB 5.3.

2 1

[Maria-developers] MWL#47 documentation
by Kristian Nielsen 12 Jan '11

12 Jan '11

Hi Daniel, I merged the MWL#47 patch into 5.2-percona, which will later be included in 5.3. I have attached the documentation for this worklog that Alexi wrote (he also implemented the feature itself). I hope you can adapt it as needed and find a good place for it in the server documentation. - Kristian. WL#47: Store in binlog text of statements that caused RBR events ================================================================ Content ~~~~~~~ 1. Annotate_rows_log_event [ ANNOTATE_ROWS_EVENT ] 2. Example 3. Master option: --binlog-annotate-rows-events 4. Slave option: --replicate-annotate-rows-events 5. mysqlbinlog option: --skip-annotate-rows-events 6. Example of mysqlbinlog output 1. Annotate_rows_log_event [ ANNOTATE_ROWS_EVENT ] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ New binlog event type - Annotate_rows_log_event - is added. The events of this type accompany rows events and describe the query which caused these rows events. In binary log, each Annotate_rows event precedes the corresponding Table map event or the first of Table map events, if there are more than one (e.g. in case of multi-delete or insert delayed). 2. Example ~~~~~~~~~~ master> DROP DATABASE IF EXISTS test; master> CREATE DATABASE test; master> USE test; master> CREATE TABLE t1(a int); master> INSERT INTO t1 VALUES (1), (2), (3); master> CREATE TABLE t2(a int); master> INSERT INTO t2 VALUES (1), (2), (3); master> CREATE TABLE t3(a int); master> INSERT DELAYED INTO t3 VALUES (1), (2), (3); master> DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3 -> WHERE t1.a=t2.a AND t2.a=t3.a; master> SHOW BINLOG EVENTS IN 'master-bin.000001'; +-------------------+------+---------------+-----------+-------------+---------------------------------------------------+ | Log_name | Pos | Event_type | Server_id | End_log_pos | Info | +-------------------+------+---------------+-----------+-------------+---------------------------------------------------+ | master-bin.000001 | 4 | Format_desc | 100 | 240 | Server ver: 5.1.44-debug-log, Binlog ver: 4 | | master-bin.000001 | 240 | Query | 100 | 331 | DROP DATABASE IF EXISTS test | | master-bin.000001 | 331 | Query | 100 | 414 | CREATE DATABASE test | | master-bin.000001 | 414 | Query | 100 | 499 | use `test`; CREATE TABLE t1(a int) | | master-bin.000001 | 499 | Query | 100 | 567 | BEGIN | | master-bin.000001 | 567 | Annotate_rows | 100 | 621 | INSERT INTO t1 VALUES (1), (2), (3) | | master-bin.000001 | 621 | Table_map | 100 | 662 | table_id: 16 (test.t1) | | master-bin.000001 | 662 | Write_rows | 100 | 706 | table_id: 16 flags: STMT_END_F | | master-bin.000001 | 706 | Query | 100 | 775 | COMMIT | | master-bin.000001 | 775 | Query | 100 | 860 | use `test`; CREATE TABLE t2(a int) | | master-bin.000001 | 860 | Query | 100 | 928 | BEGIN | | master-bin.000001 | 928 | Annotate_rows | 100 | 982 | INSERT INTO t2 VALUES (1), (2), (3) | | master-bin.000001 | 982 | Table_map | 100 | 1023 | table_id: 17 (test.t2) | | master-bin.000001 | 1023 | Write_rows | 100 | 1067 | table_id: 17 flags: STMT_END_F | | master-bin.000001 | 1067 | Query | 100 | 1136 | COMMIT | | master-bin.000001 | 1136 | Query | 100 | 1221 | use `test`; CREATE TABLE t3(a int) | | master-bin.000001 | 1221 | Query | 100 | 1289 | BEGIN | | master-bin.000001 | 1289 | Annotate_rows | 100 | 1351 | INSERT DELAYED INTO t3 VALUES (1), (2), (3) | | master-bin.000001 | 1351 | Table_map | 100 | 1392 | table_id: 18 (test.t3) | | master-bin.000001 | 1392 | Write_rows | 100 | 1426 | table_id: 18 flags: STMT_END_F | | master-bin.000001 | 1426 | Table_map | 100 | 1467 | table_id: 18 (test.t3) | | master-bin.000001 | 1467 | Write_rows | 100 | 1506 | table_id: 18 flags: STMT_END_F | | master-bin.000001 | 1506 | Query | 100 | 1575 | COMMIT | | master-bin.000001 | 1575 | Query | 100 | 1643 | BEGIN | | master-bin.000001 | 1643 | Annotate_rows | 100 | 1748 | DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3 WHERE t1.a=t2.a AND t2.a=t3.a | | master-bin.000001 | 1748 | Table_map | 100 | 1789 | table_id: 16 (test.t1) | | master-bin.000001 | 1789 | Table_map | 100 | 1830 | table_id: 17 (test.t2) | | master-bin.000001 | 1830 | Delete_rows | 100 | 1874 | table_id: 16 | | master-bin.000001 | 1874 | Delete_rows | 100 | 1918 | table_id: 17 flags: STMT_END_F | | master-bin.000001 | 1918 | Query | 100 | 1987 | COMMIT | +-------------------+------+---------------+-----------+-------------+---------------------------------------------------+ 3. Master option: --binlog-annotate-rows-events ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tells the master to write Annotate_rows events to the binary log. * Variable Name: binlog_annotate_rows_events * Scope: Global & Session * Access Type: Dynamic * Data Type: bool * Default Value: OFF Session values allows to annotate only some selected statements: ... SET SESSION binlog_annotate_rows_events=ON; ... statements to be annotated ... SET SESSION binlog_annotate_rows_events=OFF; ... statements not to be annotated ... 4. Slave option: --replicate-annotate-rows-events ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tells the slave to reproduce Annotate_rows events recieved from the master in its own binary log (sensible only in pair with log-slave-updates option). * Variable Name: replicate_annotate_rows_events * Scope: Global * Access Type: Read only (only in config file) * Data Type: bool * Default Value: OFF 5. mysqlbinlog option: --skip-annotate-rows-events ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tells mysqlbinlog to skip all Annotate_rows events in its output (by default, mysqlbinlog prints Annotate_rows events, if the binary log does contain them). 6. Example of mysqlbinlog output ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ...> mysqlbinlog.exe -vv -R --user=root --port=3306 --host=localhost master-bin.000001 /*!40019 SET @@session.max_insert_delayed_threads=0*/; /*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/; DELIMITER /*!*/; # at 4 #100516 15:36:00 server id 100 end_log_pos 240 Start: binlog v 4, server v 5.1.44-debug-log created 100516 15:36:00 at startup ROLLBACK/*!*/; BINLOG ' oNjvSw9kAAAA7AAAAPAAAAAAAAQANS4xLjQ0LWRlYnVnLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACg2O9LEzgNAAgAEgAEBAQEEgAA2QAEGggAAAAICAgCAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA= '/*!*/; # at 240 #100516 15:36:18 server id 100 end_log_pos 331 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; SET @@session.pseudo_thread_id=1/*!*/; SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=1, @@session.unique_checks=1, @@session.autocommit=1 /*!*/; SET @@session.sql_mode=0/*!*/; SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/; /*!\C latin1 *//*!*/; SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=8/*!*/; SET @@session.lc_time_names=0/*!*/; SET @@session.collation_database=DEFAULT/*!*/; DROP DATABASE IF EXISTS test /*!*/; # at 331 #100516 15:36:18 server id 100 end_log_pos 414 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; CREATE DATABASE test /*!*/; # at 414 #100516 15:36:18 server id 100 end_log_pos 499 Query thread_id=1 exec_time=0 error_code=0 use test/*!*/; SET TIMESTAMP=1274009778/*!*/; CREATE TABLE t1(a int) /*!*/; # at 499 #100516 15:36:18 server id 100 end_log_pos 567 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; BEGIN /*!*/; # at 567 # at 621 # at 662 #100516 15:36:18 server id 100 end_log_pos 621 Annotate_rows: #Q> INSERT INTO t1 VALUES (1), (2), (3) #100516 15:36:18 server id 100 end_log_pos 662 Table_map: `test`.`t1` mapped to number 16 #100516 15:36:18 server id 100 end_log_pos 706 Write_rows: table id 16 flags: STMT_END_F BINLOG ' stjvSxNkAAAAKQAAAJYCAAAAABAAAAAAAAAABHRlc3QAAnQxAAEDAAE= stjvSxdkAAAALAAAAMICAAAQABAAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA= '/*!*/; ### INSERT INTO test.t1 ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t1 ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t1 ### SET ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ # at 706 #100516 15:36:18 server id 100 end_log_pos 775 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; COMMIT /*!*/; # at 775 #100516 15:36:18 server id 100 end_log_pos 860 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; CREATE TABLE t2(a int) /*!*/; # at 860 #100516 15:36:18 server id 100 end_log_pos 928 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; BEGIN /*!*/; # at 928 # at 982 # at 1023 #100516 15:36:18 server id 100 end_log_pos 982 Annotate_rows: #Q> INSERT INTO t2 VALUES (1), (2), (3) #100516 15:36:18 server id 100 end_log_pos 1023 Table_map: `test`.`t2` mapped to number 17 #100516 15:36:18 server id 100 end_log_pos 1067 Write_rows: table id 17 flags: STMT_END_F BINLOG ' stjvSxNkAAAAKQAAAP8DAAAAABEAAAAAAAAABHRlc3QAAnQyAAEDAAE= stjvSxdkAAAALAAAACsEAAAQABEAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA= '/*!*/; ### INSERT INTO test.t2 ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t2 ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t2 ### SET ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ # at 1067 #100516 15:36:18 server id 100 end_log_pos 1136 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; COMMIT /*!*/; # at 1136 #100516 15:36:18 server id 100 end_log_pos 1221 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; CREATE TABLE t3(a int) /*!*/; # at 1221 #100516 15:36:18 server id 100 end_log_pos 1289 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; BEGIN /*!*/; # at 1289 # at 1351 # at 1392 #100516 15:36:18 server id 100 end_log_pos 1351 Annotate_rows: #Q> INSERT DELAYED INTO t3 VALUES (1), (2), (3) #100516 15:36:18 server id 100 end_log_pos 1392 Table_map: `test`.`t3` mapped to number 18 #100516 15:36:18 server id 100 end_log_pos 1426 Write_rows: table id 18 flags: STMT_END_F BINLOG ' stjvSxNkAAAAKQAAAHAFAAAAABIAAAAAAAAABHRlc3QAAnQzAAEDAAE= stjvSxdkAAAAIgAAAJIFAAAQABIAAAAAAAEAAf/+AQAAAA== '/*!*/; ### INSERT INTO test.t3 ### SET ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ # at 1426 # at 1467 #100516 15:36:18 server id 100 end_log_pos 1467 Table_map: `test`.`t3` mapped to number 18 #100516 15:36:18 server id 100 end_log_pos 1506 Write_rows: table id 18 flags: STMT_END_F BINLOG ' stjvSxNkAAAAKQAAALsFAAAAABIAAAAAAAAABHRlc3QAAnQzAAEDAAE= stjvSxdkAAAAJwAAAOIFAAAQABIAAAAAAAEAAf/+AgAAAP4DAAAA '/*!*/; ### INSERT INTO test.t3 ### SET ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### INSERT INTO test.t3 ### SET ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ # at 1506 #100516 15:36:18 server id 100 end_log_pos 1575 Query thread_id=2 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; COMMIT /*!*/; # at 1575 #100516 15:36:18 server id 100 end_log_pos 1643 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; BEGIN /*!*/; # at 1643 # at 1748 # at 1789 # at 1830 # at 1874 #100516 15:36:18 server id 100 end_log_pos 1748 Annotate_rows: #Q> DELETE t1, t2 FROM t1 INNER JOIN t2 INNER JOIN t3 #Q> WHERE t1.a=t2.a AND t2.a=t3. #100516 15:36:18 server id 100 end_log_pos 1789 Table_map: `test`.`t1` mapped to number 16 #100516 15:36:18 server id 100 end_log_pos 1830 Table_map: `test`.`t2` mapped to number 17 #100516 15:36:18 server id 100 end_log_pos 1874 Delete_rows: table id 16 #100516 15:36:18 server id 100 end_log_pos 1918 Delete_rows: table id 17 flags: STMT_END_F BINLOG ' stjvSxNkAAAAKQAAAP0GAAAAABAAAAAAAAAABHRlc3QAAnQxAAEDAAE= stjvSxNkAAAAKQAAACYHAAAAABEAAAAAAAAABHRlc3QAAnQyAAEDAAE= stjvSxlkAAAALAAAAFIHAAAAABAAAAAAAAAAAf/+AQAAAP4CAAAA/gMAAAA= ### DELETE FROM test.t1 ### WHERE ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### DELETE FROM test.t1 ### WHERE ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### DELETE FROM test.t1 ### WHERE ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ stjvSxlkAAAALAAAAH4HAAAQABEAAAAAAAEAAf/+AQAAAP4CAAAA/gMAAAA= '/*!*/; ### DELETE FROM test.t2 ### WHERE ### @1=1 /* INT meta=0 nullable=1 is_null=0 */ ### DELETE FROM test.t2 ### WHERE ### @1=2 /* INT meta=0 nullable=1 is_null=0 */ ### DELETE FROM test.t2 ### WHERE ### @1=3 /* INT meta=0 nullable=1 is_null=0 */ # at 1918 #100516 15:36:18 server id 100 end_log_pos 1987 Query thread_id=1 exec_time=0 error_code=0 SET TIMESTAMP=1274009778/*!*/; COMMIT /*!*/; DELIMITER ; # End of log file ROLLBACK /* added by mysqlbinlog */; /*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

1 0

[Maria-developers] MWL#36 documentation
by Kristian Nielsen 12 Jan '11

12 Jan '11

Hi Daniel, While merging Percona patches, I noticed a couple of issues with our documentation relating to MWL#36, I was hoping you could handle them: - The MWL#36 is mentioned in the changelog/release notes: http://kb.askmonty.org/v/mariadb-520-release-notes However it seems to be missing from "mariadb-vs-mysql": http://kb.askmonty.org/v/mariadb-versus-mysql-features - There is some documentation of the MWL#36 in the form of a table entry for --rewrite-db here: http://kb.askmonty.org/v/mysqlbinlog However, that page mentions the feature introduced in MariaDB 5.2.1, while the release notes say 5.2.0. I wonder which is correct? - Kristian.

1 0

[Maria-developers] Multiple default values for timestamps
by Dolf Schimmel 09 Jan '11

09 Jan '11

Hey folks, On IRC I read somewhere that multiple timestamps cant have multiple default values using NOW() (error ER_TOO_MUCH_AUTO_TIMESTAMP_COLS). I tried to find out why this limitation is in place, but was not able to do so. The only thing I (or rather someone in #mysql and #maria) was able to find was this, in sql/field.cc (line 4729): > Actually SQL-99 says that we should allow niladic functions (like NOW()) > as defaults for any field. Current limitations (only NOW() and only > for one TIMESTAMP field) are because of restricted binary .frm format > and should go away in the future. I removed the check that spits out this error and updated the tests. Now I'll admit I'm not sure how to properly test this, but so far the entire testsuite passes. It may be that I'm missing any reasons for this limitation, or that tests may be missing/inaccurate. If you have any opinions on this, please let me know. You can find it in: lp:~freeaqingme/maria/improv-allowMultipleCurTimestampInDefaultOnTable Regards, Dolf Schimmel -- Freeaqingme p.s. Sorry for the long branchname, couldn't think of something shorter that was still descriptive :D

2 3

[Maria-developers] WL#173 New (by Sergei): temporal types with sub-second resolution
by worklog-noreply＠askmonty.org 09 Jan '11

09 Jan '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: temporal types with sub-second resolution CREATION DATE..: Sun, 09 Jan 2011, 20:08 SUPERVISOR.....: Sergei IMPLEMENTOR....: Sergei COPIES TO......: Monty CATEGORY.......: Server-Sprint TASK ID........: 173 (https://askmonty.org/worklog/?tid=173) VERSION........: Server-5.3 STATUS.........: Assigned PRIORITY.......: 80 WORKED HOURS...: 0 ESTIMATE.......: 80 (hours remain) ORIG. ESTIMATE.: 80 PROGRESS NOTES: DESCRIPTION: We will add a support for timestamps (and other temporal types) with a sub-second resolution. Syntax ^^^^^^ The syntax for declaring a column is the conventional TIMESTAMP(X) DATETIME(X) TIME(X) where X is the scale - that is, number of digits after the decimal dot. TIMESTAMP(0) is the same as the current TIMESTAMP. The existing syntax (without specifying the scale) will, of course, work as before. X=6 means microseconds, X=9 means nanoseconds, X=12 means picoseconds. The max supported value of X is [undecided], but will be no less than 6. Possibly, we will do 6 in this WL - because it keeps syntax and protocol changes to the minimum, microseconds are already supported there. If needed, we will increase the timestamp precision later - the implementation (see below) needs to keep it in mind. The time and datetime literals can be written with the fractional part, for example '2011-01-08 20:29:26.1234567890'. This is alrteady supported. Client-server protocol ^^^^^^^^^^^^^^^^^^^^^^ We will not change the binary client-server protocol. It only supports microseconds in the MYSQL_TIME::second_part - we will truncate longer timestamps to this precision. Show commands and I_S ^^^^^^^^^^^^^^^^^^^^^ SHOW COLUMNS and SHOW CREATE TABLE will show TIMESTAMP(X) as appropriate (similar to INT(N) and DECIMAL(M,N) types). I_S.COLUMNS will *not* show '(X)' in the DATA_TYPE column, but it *will* show it in the COLUMN_TYPE column. It will show X in the new DATETIME_PRECISION column. Functions ^^^^^^^^^ The following functions need to be fixed to support sub-seconds: CAST() - as DATETIME(X), etc CONVERT_TZ() SEC_TO_TIME() TIME_TO_SEC() MAKETIME() - perhaps? FROM_UNIXTIME() - probably not UNIX_TIMESTAMP() - probably not UTC_TIMESTAMP(), UTC_TIME(), NOW(), CURTIME() and synonyms - probably not, high-precision NOW() is a separate task P.S. See also http://forge.mysql.com/worklog/task.php?id=946 ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] The query cache patch fixed by me and then Monty (most changes by him)
by Oleksandr Byelkin 07 Jan '11

07 Jan '11

Hi! Here is changes which was done: - Fixed switching off of the query cache -- memory freed now -- after completely switching of it could be switched on again - Cleaned up saving the query without comments and space - Added all the missing test cases (and checked results) - Added more symbols to LEX to make parsing faster (not part of this thing, but I thought it was better to get this done now as I was looking at the code) - Fixed all the issues that I had in my review of query parsing - Cleaned up mysql-tests -- Made test results easier to read -- removed 'percona' prefix from tests names -- Made test result files notable smaller - Added 'thd' to query_cache::invalidate calls, to remove some current_thd usages - Added variable thd->query_cache_is_valid, that is set to 1 if query_cache could possible read query from the query_cache -- If not, there is no reason to put the query in the cache The above change allowed me to remove safe_to_cache_queries from send_result_to_client() and make this part of the code not depending in lex_start() - simplified a couple of functions to use pointers instead of index - Fixed bug where SQL_NO_CACHE was not detected if followed by tab, newline or return i> that's about it 2 Vadim & Oleg: If you OK with changes above and the patch then it will be included in our tree.

2 3

[Maria-developers] [patch] A few typos
by Dolf Schimmel 07 Jan '11

07 Jan '11

Morning folks, I was looking at the source for a certain function in MariaDB (see the patch and you'll know which one :D ). While grepping I found a couple of typos and since I don't have commit rights, and couldn't find where to send the patch, I decided to send it here :) The diff is made against trunk, but I guess it should be fairly easy to patch against other branches as well. Kind regards, Dolf Schimmel -- Freeaqingme

2 1