March 2019 - developers - lists.mariadb.org

Re: [Maria-developers] 62d62228aa6: Static current schema and state change trackers
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! Why two trackers are static and the other two aren't? Please, explain it in a comment. On Mar 25, Sergey Vojtovich wrote: > revision-id: 62d62228aa6 (mariadb-10.3.12-91-g62d62228aa6) > parent(s): 61b9bffbedc > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-19 23:40:07 +0400 > message: > > Static current schema and state change trackers > > Saves 2 new/delete per connection. > > Part of MDEV-14984 - regression in connect performance Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 1

Re: [Maria-developers] db9854b7d48: Allocate Transaction_state_tracker statically
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! ok to push On Mar 25, Sergey Vojtovich wrote: > revision-id: db9854b7d48 (mariadb-10.3.12-92-gdb9854b7d48) > parent(s): 62d62228aa6 > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-19 23:40:07 +0400 > message: > > Allocate Transaction_state_tracker statically > > 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] 61b9bffbedc: Allocate orig_list statically
by Sergei Golubchik 25 Mar '19

25 Mar '19

Hi, Sergey! ok to push On Mar 25, Sergey Vojtovich wrote: > revision-id: 61b9bffbedc (mariadb-10.3.12-90-g61b9bffbedc) > parent(s): 9dd4fcb3f7c > author: Sergey Vojtovich <svoj(a)mariadb.org> > committer: Sergey Vojtovich <svoj(a)mariadb.org> > timestamp: 2019-03-19 23:39:19 +0400 > message: > > Allocate orig_list statically > > tool_list is a temporary list needed only for SET SESSION > session_track_system_variables, so allocate it on stack instead. > > Sane reinit() calls. > > Saves 2 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] 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