- developers - lists.mariadb.org

Re: [Maria-developers] 9dd4fcb3f7c: Get rid of not implemented SESSION_GTIDS_TRACKER
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! ok to push On Mar 25, Sergey Vojtovich wrote: > revision-id: 9dd4fcb3f7c (mariadb-10.3.12-89-g9dd4fcb3f7c) > parent(s): 72e4e57a52a > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-19 17:28:09 +0400 > message: > > Get rid of not implemented SESSION_GTIDS_TRACKER > > One less new/delete per connection. > > Part of MDEV-14984 - regression in connect performance > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 4c0eb412ff5: A proper State_tracker::m_changed enacpsulation
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! ok to push On Mar 25, Sergey Vojtovich wrote: > revision-id: 4c0eb412ff5 (mariadb-10.3.12-85-g4c0eb412ff5) > parent(s): 69b33fca8cc > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-18 22:51:45 +0400 > message: > > A proper State_tracker::m_changed enacpsulation > > Note: preserved original behaviour, where remaining trackers are not reset > on error from store(). This effectively means subsequent statements will > start tracking from unclean state. > > Part of MDEV-14984 - regression in connect performance > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 68abb07298b: Cleanup session tracker redundnacy
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! ok to push On Mar 25, Sergey Vojtovich wrote: > revision-id: 68abb07298b (mariadb-10.3.12-87-g68abb07298b) > parent(s): facc973189a > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-18 22:51:58 +0400 > message: > > Cleanup session tracker redundnacy > > - m_enabled is initialised by the base class constructor > - removed unused schema_track_inited > - moved Transaction_state_tracker constructor to declaration > - common enable() > - removed unused Session_sysvars_tracker::check_str() > - classes are "private" by default > - don't even try to compile for embedded > > Part of MDEV-14984 - regression in connect performance > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] facc973189a: Session_sysvars_tracker::vars_list cleanups
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! On Mar 25, Sergey Vojtovich wrote: > revision-id: facc973189a (mariadb-10.3.12-86-gfacc973189a) > parent(s): 4c0eb412ff5 > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-18 22:51:58 +0400 > message: > > Session_sysvars_tracker::vars_list cleanups > > - return proper type > - removed useless node argument > - removed useless mem_flag > - classes are "private" by default > - simplified iterators > > Part of MDEV-14984 - regression in connect performance ok to push Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-18734 ASAN heap-use-after-free in my_strnxfrm_simple_internal upon update on versioned partitioned table
by Aleksey Midenkov 25 Mar '19

25 Mar '19

Hi, Sergei! ha_partition::handle_ordered_index_scan() stores records in m_ordered_rec_buffer. Then TABLE::update_virtual_fields() updates blob buffer and frees the old one. Then ha_partition::return_top_record() returns record from m_ordered_rec_buffer with stale blob pointer. What should we do with this? I propose to duplicate blob buffer when record gets into m_ordered_rec_buffer. More details can be found here: https://github.com/tempesta-tech/mariadb/issues/581 -- All the best, Aleksey Midenkov @midenok

2 4

[Maria-developers] question about running latest build.
by Luuk 24 Mar '19

24 Mar '19

After noticing that a bug i reported was set to 'solved' i wanted to see/check that. So, i downloaded/compiled Now i seem to be able to run the server, but i am unable to connect using 'mysql.exe' Luuk@ZES MINGW64 /d/TEMP/server (master) $ bld/client/RelWithDebInfo/mysqladmin -h localhost -u root version D:\TEMP\server\bld\client\RelWithDebInfo\mysqladmin.exe Ver 9.1 Distrib 10.4.4-MariaDB, for Win32 on AMD64 Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Server version 10.4.4-MariaDB Protocol version 10 Connection localhost via TCP/IP TCP port 3306 Uptime: 23 min 15 sec Threads: 7 Questions: 4 Slow queries: 0 Opens: 16 Flush tables: 1 Open tables: 10 Queries per second avg: 0.002 Luuk@ZES MINGW64 /d/TEMP/server (master) $ bld/client/RelWithDebInfo/mysql -h localhost -u root #### no reaction, killin 'mysql.exe' just add another 'Aborted connection' to the server-log.... QUESTION: What am i missing here? The log from the server (Windows 10): Luuk@ZES MINGW64 /d/TEMP/server/bld (master) $ sql/RelWithDebInfo/mysqld.exe --console 2019-03-24 16:20:01 0 [Note] D:\TEMP\server\bld\sql\RelWithDebInfo\mysqld.exe (mysqld 10.4.4-MariaDB) starting as process 2024 ... 2019-03-24 16:20:01 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions 2019-03-24 16:20:01 0 [Note] InnoDB: Uses event mutexes 2019-03-24 16:20:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2019-03-24 16:20:01 0 [Note] InnoDB: Number of pools: 1 2019-03-24 16:20:01 0 [Note] InnoDB: Using SSE2 crc32 instructions 2019-03-24 16:20:01 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M 2019-03-24 16:20:01 0 [Note] InnoDB: Completed initialization of buffer pool 2019-03-24 16:20:01 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2019-03-24 16:20:01 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2019-03-24 16:20:01 0 [Note] InnoDB: Setting file '.\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2019-03-24 16:20:01 0 [Note] InnoDB: File '.\ibtmp1' size is now 12 MB. 2019-03-24 16:20:01 0 [Note] InnoDB: Waiting for purge to start 2019-03-24 16:20:01 0 [Note] InnoDB: 10.4.4 started; log sequence number 139881; transaction id 21 2019-03-24 16:20:01 0 [Note] InnoDB: Loading buffer pool(s) from D:\TEMP\server\bld\sql\data\ib_buffer_pool 2019-03-24 16:20:01 0 [Note] Plugin 'FEEDBACK' is disabled. 2019-03-24 16:20:01 0 [Note] InnoDB: Buffer pool(s) load completed at 190324 16:20:01 2019-03-24 16:20:01 0 [Note] Server socket created on IP: '::'. 2019-03-24 16:20:01 0 [Note] Reading of all Master_info entries succeded 2019-03-24 16:20:01 0 [Note] Added new Master_info '' to hash table 2019-03-24 16:20:01 0 [Note] D:\TEMP\server\bld\sql\RelWithDebInfo\mysqld.exe: ready for connections. Version: '10.4.4-MariaDB' socket: '' port: 3306 Source distribution 2019-03-24 16:21:24 8 [Warning] Aborted connection 8 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets) 2019-03-24 16:21:49 9 [Warning] Aborted connection 9 to db: 'unconnected' user: 'root' host: 'localhost' (Got an error reading communication packets)

1 0

Re: [Maria-developers] d260871fccc: MDEV-18967 Load data in system version with long unique does not work
by Sergei Golubchik 20 Mar '19

20 Mar '19

Hi, Sachin! ok to push! On Mar 20, Sachin Setiya wrote: > revision-id: d260871fccc (mariadb-10.4.3-87-gd260871fccc) > parent(s): f6166101e0f > author: Sachin <sachin.setiya(a)mariadb.com> > committer: Sachin <sachin.setiya(a)mariadb.com> > timestamp: 2019-03-19 16:43:43 +0530 > message: > > MDEV-18967 Load data in system version with long unique does not work > > Update system versioning fields before generaled columns for left out > fill_record > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] f6166101e0f: MDEV-18904 Assertion `m_part_spec.start_part >= m_part_spec.end_part' failed in ha_partition::index_read_idx_map
by Sergei Golubchik 20 Mar '19

20 Mar '19

Hi, Sachin! On Mar 20, Sachin Setiya wrote: > revision-id: f6166101e0f (mariadb-10.4.3-86-gf6166101e0f) > parent(s): 8076c594ce2 > author: sachinsetia1001(a)gmail.com <sachin.setiya(a)mariadb.com> > committer: Sachin <sachin.setiya(a)mariadb.com> > timestamp: 2019-03-19 16:43:43 +0530 > message: > > MDEV-18904 Assertion `m_part_spec.start_part >= m_part_spec.end_part' failed in ha_partition::index_read_idx_map > > We do not support long unique index in partition. Why not? I would think that the assert is wrong, there is no reason why ha_partition::index_read_idx_map() would always hit just one partition. ha_partition::index_read_map() doesn't have this assert. And if you check the history of the assert you'll find that the comment originally was /* How can it be more than one partition with the current use? */ So, apparently now you've introduced a new "use" and there can be more than one partition, and removing the assert looks justified. > +CREATE TABLE t1 (a int , unique(a) using hash) PARTITION BY HASH (a) PARTITIONS 2; > +ERROR HY000: Long unique index is not supported in partition Also - for the future - there are no "long unique" indexes from the user point of view. This is only an internal name. The SQL syntax does use "long unique" concept, documentation doesn't, error messages don't. That is, users simply won't understand what you mean here. If we'll need an error here, I'd suggest, for example, HASH UNIQUE indexes cannot be used in partitioned tables. but it's not strictly correct, if some engine would implement hash indexes natively. The more precise message could be HASH UNIQUE indexes cannot be used in par titioned MyISAM tables. or Partitioned MyISAM tables do not support HASH UNIQUE indexes. (where "MyISAM" is a parameter, of course). But, again, I am not yet convinced that we need this limitation at all. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 500d909: MDEV-18741: Optimizer trace: multi-part key ranges are printed incorrectly
by Sergey Petrunia 18 Mar '19

18 Mar '19

> revision-id: 500d909a795022255fb6f6c44cd310636afc0b5a (mariadb-10.3.6-226-g500d909) > parent(s): 88d89ee0bae24b71416c2af4f4c2f2be7b6a033a > author: Varun Gupta > committer: Varun Gupta > timestamp: 2019-03-11 20:20:35 +0530 > message: > > MDEV-18741: Optimizer trace: multi-part key ranges are printed incorrectly > > Keys with multi-key parts were not being printed correctly, only the first key part > was getting printed. > Fixed it by making sure append_range_all_keyparts function is called for the remaining keyparts. > ... > diff --git a/mysql-test/main/opt_trace.result b/mysql-test/main/opt_trace.result > index 4c3e2b3..a4c2b86 100644 > --- a/mysql-test/main/opt_trace.result > +++ b/mysql-test/main/opt_trace.result > @@ -6022,3 +6022,428 @@ t_outer_2.a in (select t_inner_3.a from t2 t_inner_3, t1 t_inner_4) { > set @@optimizer_switch= @save_optimizer_switch; > drop table t1,t2; > set optimizer_trace='enabled=off'; > +# > +# MDEV-18741: Optimizer trace: multi-part key ranges are printed incorrectly > +# > +create table t0(a int); > +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); > +create table one_k (a int); > +insert into one_k select A.a + B.a*10 + C.a*100 from t0 A, t0 B, t0 C; > +create table t1 ( a int, b int, c int, d int, key (a,b), key(c,d)); > +insert into t1 select a,a,a,a from one_k; > +set optimizer_trace=1; > +explain format=json select * from t1 where a > 10 and b < 10 and c=0 and d=1; ... > +select * from INFORMATION_SCHEMA.OPTIMIZER_TRACe; This produces a lot of irrelevant output. Can you use something like select JSON_DETAILED(JSON_EXTRACT(a, '$**.range_analysis')) from optimizer_trace to select on the part of the trace that we need? > + "analyzing_range_alternatives": { > + "range_scan_alternatives": [ > + { > + "index": "a", > + "ranges": ["10 < a AND NULL < b < 10"], This is not a valid range. If one forces this quick select to be picked for the query plan, they can look into .trace and see the ranges: explain format=json select * from t1 force index (a) where a > 10 and b < 10; T@19 : | | | | | | | | | | >print_quick quick range select, key a, length: 5 10 < X other_keys: 0x0: T@19 : | | | | | | | | | | <print_quick (you can also try with a >=10 to see a different kind of range being produced). (One could argue that what is printed is a representation of the SEL_ARG graph, but in that case it is extremely confusing. I think, we should start with showing ranges, not SEL_ARG graphs). I think, we should not try to intrepret the SEL_ARG graph ourselves but rather use sel_arg_range_seq_init / sel_arg_range_seq_next to produce ranges that can be printed. Any objections to this? > + "rowid_ordered": false, > + "using_mrr": false, > + "index_only": false, > + "rows": 989, > + "cost": 1272.8, > + "chosen": false, > + "cause": "cost" > + }, > + { > + "index": "c", > + "ranges": ["0 <= c <= 0 AND 1 <= d <= 1"], > + "rowid_ordered": true, > + "using_mrr": false, > + "index_only": false, > + "rows": 1, > + "cost": 2.3783, > + "chosen": true > + } > + ], BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] ASAN segfaults on vcol case
by Aleksey Midenkov 18 Mar '19

18 Mar '19

This case segfaults in ASAN code: delimiter ~~ create or replace procedure t1() begin create or replace table t1 ( b tinytext, v text as (b) virtual ); end~~ delimiter ; call t1; Both in 10.3 and 10.4 in different places. Does someone know about such ASAN faults? -- All the best, Aleksey Midenkov @midenok

2 2