- developers - lists.mariadb.org

[Maria-developers] MariaDB finally in Debian officially (Fwd: Debian 8 "Jessie" released)
by Otto Kekäläinen 26 Apr '15

26 Apr '15

Hello! Debian 8 "Jessie" has been released to today. It is the first official Debian release that ships with MariaDB (it has MariaDB 10.0.16 and MySQL 5.5.42). MariaDB client for C (the LGPL version) is also included. Release notes[1] state that in Debian 9 only one MySQL variant will be shipped. Hopefully the decision will tip towards MariaDB. The MariaDB "request for packaging" issue[2] was opened in bugs.debian.org in 2010. I started doing MariaDB packaging for Debian in 2013. The path here has been long and I am glad that this milestone is finally reached. [1] https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.… [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=565308 ---------- Forwarded message ---------- From: Paul Wise <pabs(a)debian.org> Date: 2015-04-26 5:28 GMT+03:00 Subject: Debian 8 "Jessie" released To: debian-announce(a)lists.debian.org ------------------------------------------------------------------------ The Debian Project https://www.debian.org/ Debian 8 "Jessie" released press(a)debian.org April 25th, 2015 https://www.debian.org/News/2015/20150426 ------------------------------------------------------------------------ After almost 24 months of constant development the Debian project is proud to present its new stable version 8 (code name "Jessie"), which will be supported for the next 5 years thanks to the combined work of the Debian Security team [1] and of the Debian Long Term Support [2] team. 1: http://security-team.debian.org/ 2: https://wiki.debian.org/LTS "Jessie" ships with a new default init system, systemd. The systemd suite provides many exciting features such as faster boot times, cgroups for services, and the possibility of isolating part of the services. The sysvinit init system is still available in "Jessie". The UEFI ("Unified Extensible Firmware Interface") support introduced in "Wheezy" has also been greatly improved in Jessie. This includes workarounds for many known firmware bugs, support for UEFI on 32-bit systems, and support for 64-bit kernels with 32-bit UEFI firmware (with the latter being included only on our amd64/i386 "multi-arch" installation media). Since the previous release, members of the Debian project have also made important improvements to our supporting services. One of these is a browsable view of all source code shipped in Debian [3] currently available at sources.debian.net [4]. Of course, with over 20,000 source packages, it can be quite daunting to locate the right file. Therefore, we are also very pleased to present Debian Code Search [5], available at codesearch.debian.net [6]. Both services are complemented by a completely rewritten and more reponsive package tracking system [7]. 3: https://www.debian.org/News/weekly/2013/14/#sources 4: https://sources.debian.net 5: https://www.debian.org/News/weekly/2014/17/#DCS 6: https://codesearch.debian.net/ 7: https://tracker.debian.org/ This release includes numerous updated software packages, such as: * Apache 2.4.10 * Asterisk 11.13.1 * GIMP 2.8.14 * an updated version of the GNOME desktop environment 3.14 * GNU Compiler Collection 4.9.2 * Icedove 31.6.0 (an unbranded version of Mozilla Thunderbird) * Iceweasel 31.6.0esr (an unbranded version of Mozilla Firefox) * KDE Plasma Workspaces and KDE Applications 4.11.13 * LibreOffice 4.3.3 * Linux 3.16.7-ctk9 * MariaDB 10.0.16 and MySQL 5.5.42 * Nagios 3.5.1 * OpenJDK 7u75 * Perl 5.20.2 * PHP 5.6.7 * PostgreSQL 9.4.1 * Python 2.7.9 and 3.4.2 * Samba 4.1.17 * Tomcat 7.0.56 and 8.0.14 * Xen Hypervisor 4.4.1 * the Xfce 4.10 desktop environment * more than 43,000 other ready-to-use software packages, built from nearly 20,100 source packages. With this broad selection of packages and its traditional wide architecture support, Debian once again stays true to its goal of being the universal operating system. It is suitable for many different use cases: from desktop systems to netbooks; from development servers to cluster systems; and for database, web, or storage servers. At the same time, additional quality assurance efforts like automatic installation and upgrade tests for all packages in Debian's archive ensure that "Jessie" fulfills the high expectations that users have of a stable Debian release. A total of ten architectures are supported: 32-bit PC / Intel IA-32 (i386), 64-bit PC / Intel EM64T / x86-64 (amd64), Motorola/IBM PowerPC (powerpc for older hardware and ppc64el for the new 64-bit (little- endian)), MIPS (mips (big-endian) and mipsel (little-endian)), IBM S/390 (64-bit s390x) and for ARM, armel and armhf for old and new 32-bit hardware, plus arm64 for the new 64-bit "AArch64" architecture. Want to give it a try? ---------------------- If you simply want to try Debian 8 "Jessie" without having to install it, you can use a special image, known as a live image, available for CDs, USB sticks, and netboot setups. Initially, these images are provided for the amd64 and i386 architectures only. It is also possible to use these live images to install Debian. More information is available from the Debian Live homepage [8]. 8: http://live.debian.net/ If, instead, you want to install it to your computer's permanent storage, you can choose from a range of installation media, such as Blu- ray Discs, DVDs, CDs, and USB sticks, or from the network. Several desktop environments — GNOME, KDE Plasma Desktop and Applications, Xfce, and LXDE — may be installed through CD images; the desired one may be chosen from the boot menus of the CDs/DVDs. In addition, multi- architecture CDs and DVDs are available which support installation of multiple architectures from a single disc. Or you can always create bootable USB installation media (see the Installation Guide [9] for more details). For cloud users Debian also offers pre-built OpenStack images [10], ready to use. 9: https://www.debian.org/releases/jessie/installmanual 10: http://cdimage.debian.org/cdimage/openstack/current/ The installation images may be downloaded right now via bittorrent [11] (the recommended method), jigdo [12], or HTTP [13]; see Debian on CDs [14] for further information. "Jessie" will soon be available on physical DVD, CD-ROM, and Blu-ray Discs from numerous vendors [15] too. 11: https://www.debian.org/CD/torrent-cd/ 12: https://www.debian.org/CD/jigdo-cd/#which 13: https://www.debian.org/CD/http-ftp/ 14: https://www.debian.org/CD/ 15: https://www.debian.org/CD/vendors Upgrading Debian ---------------- Upgrades to Debian 8 from the previous release, Debian 7 (codenamed "Wheezy"), are automatically handled by the apt-get package management tool for most configurations. As always, Debian systems may be upgraded painlessly, in place, without any forced downtime, but it is strongly recommended to read the release notes [16] as well as the installation guide [17] for possible issues, and for detailed instructions on installing and upgrading. The release notes will be further improved and translated to additional languages in the weeks after the release. 16: https://www.debian.org/releases/jessie/releasenotes 17: https://www.debian.org/releases/jessie/installmanual About Debian ------------ Debian is a free operating system, developed by thousands of volunteers from all over the world who collaborate via the Internet. The Debian project's key strengths are its volunteer base, its dedication to the Debian Social Contract and Free Software, and its commitment to provide the best operating system possible. Debian 8 is another important step in that direction. Contact Information ------------------- For further information, please visit the Debian web pages at https://www.debian.org/ or send mail to <press(a)debian.org>. -- To UNSUBSCRIBE, email to debian-announce-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: https://lists.debian.org/20150426022805.GA7860@chianamo -- Check out our blog at http://seravo.fi/blog and follow @ottokekalainen

2 2

Re: [Maria-developers] Rev 4407: MDEV-6916: Upgrade from MySQL to MariaDB breaks already created views
by Sergei Golubchik 25 Apr '15

25 Apr '15

Hi, Sanja! On Feb 09, sanja(a)askmonty.org wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-6916-check_view/ > > ------------------------------------------------------------ > revno: 4407 > revision-id: sanja(a)askmonty.org-20150209014828-kx3cr36hgrvjhtrg > parent: svoj(a)mariadb.org-20150114135038-v50g2cul4vce63h8 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-6916-check_view > timestamp: Mon 2015-02-09 02:48:28 +0100 > message: > MDEV-6916: Upgrade from MySQL to MariaDB breaks already created views > > CHECK/REPAIR commands and mysql_upgradesupport for upgrade from MySQL server support. > === modified file 'client/mysql_upgrade.c' > --- a/client/mysql_upgrade.c 2014-03-27 21:26:58 +0000 > +++ b/client/mysql_upgrade.c 2015-02-09 01:48:28 +0000 > @@ -150,6 +151,14 @@ static struct my_option my_long_options[ > &opt_not_used, &opt_not_used, 0, GET_BOOL, NO_ARG, 1, 0, 0, 0, 0, 0}, > {"version", 'V', "Output version information and exit.", 0, 0, 0, > GET_NO_ARG, NO_ARG, 0, 0, 0, 0, 0, 0}, > + {"mysql-upgrade", 'y', > + "Skip automatic detection MySQL and assume that we upgrade it", > + &opt_mysql_upgrade, &opt_mysql_upgrade, 0, GET_BOOL, NO_ARG, > + 0, 0, 0, 0, 0, 0}, > + {"skip-mysql-upgrade", 'Y', > + "Skip view algorithm upgrade from MySQL", > + &opt_skip_mysql_upgrade, &opt_skip_mysql_upgrade, 0, GET_BOOL, NO_ARG, > + 0, 0, 0, 0, 0, 0}, I remember I've already commented on that in my previous review. Here you are, again: === Those two are very bad option names. First, $ mysql_upgrade --mysql-upgrade looks plain weird. $ mysql_upgrade --skip-mysql-upgrade is even worse. And what about $ mysql_upgrade --mysql-upgrade --skip-mysql-upgrade Second, "skip" is the prefix automatically recognized by my_getopt. Normally, --skip-xxx is the same as --xxx=0. But now you're introducing --skip-mysql-upgrade which is very different from --skip-mysql-upgrade. While simultaneously adding support for --skip-skip-mysql-upgrade. A better option would be --fix-view-algorithm = { AUTO | ALWAYS | NEVER } === In fact, I'd rather remove this option completely. You can simply add if (!is_mysql()) return; to run_mysqlcheck_views() > {"version-check", 'k', "Run this program only if its \'server version\' " > "matches the version of the server to which it's connecting, (enabled by " > "default); use --skip-version-check to avoid this check. Note: the \'server " > @@ -344,6 +353,14 @@ get_one_option(int optid, const struct m > case OPT_DEFAULT_AUTH: /* --default-auth */ > add_one_option(&conn_args, opt, argument); > break; > + case 'y': > + opt_mysql_upgrade= 1; > + add_option= FALSE; > + break; > + case 'Y': > + opt_skip_mysql_upgrade= 1; > + add_option= FALSE; This is a wrong way of implementing command-line options. Let my_getopt do its job and don't set values manually. > + break; > } > > if (add_option) > @@ -754,6 +771,23 @@ static int run_mysqlcheck_upgrade(void) > NULL); > } > > +static int run_mysqlcheck_views(void) > +{ > + if (!opt_mysql_upgrade) > + return 0; > + verbose("Phase 0: Fixing views"); Again, was in my previous review: === No "Phase 0" please, renumber all phases to start from 1. === > + print_conn_args("mysqlcheck"); > + return run_tool(mysqlcheck_path, > + NULL, /* Send output from mysqlcheck directly to screen */ > + "--no-defaults", > + ds_args.str, > + "--all-databases", > + "--mysql-upgrade", > + opt_verbose ? "--verbose": "", > + opt_silent ? "--silent": "", > + "2>&1", > + NULL); > +} > > static int run_mysqlcheck_fixnames(void) > { > === modified file 'client/mysqlcheck.c' > --- a/client/mysqlcheck.c 2014-02-17 10:00:51 +0000 > +++ b/client/mysqlcheck.c 2015-02-09 01:48:28 +0000 > @@ -196,6 +197,9 @@ static struct my_option my_long_options[ > NO_ARG, 0, 0, 0, 0, 0, 0}, > {"version", 'V', "Output version information and exit.", 0, 0, 0, GET_NO_ARG, > NO_ARG, 0, 0, 0, 0, 0, 0}, > + {"mysql-upgrade", 'y', > + "Fix view algorithm view field if it is not new MariaDB view.", > + 0, 0, 0, GET_NO_ARG, NO_ARG, 0, 0, 0, 0, 0, 0}, > {0, 0, 0, 0, 0, 0, GET_NO_ARG, NO_ARG, 0, 0, 0, 0, 0, 0} > }; > > @@ -332,7 +336,13 @@ get_one_option(int optid, const struct m > case 'v': > verbose++; > break; > - case 'V': print_version(); exit(0); > + case 'V': > + print_version(); exit(0); > + break; > + case 'y': > + what_to_do= DO_REPAIR; > + opt_mysql_upgrade= 1; > + break; See above. > case OPT_MYSQL_PROTOCOL: > opt_protocol= find_type_or_exit(argument, &sql_protocol_typelib, > opt->name); > @@ -595,7 +605,15 @@ static int process_all_tables_in_db(char > for (end = tables + 1; (row = mysql_fetch_row(res)) ;) > { > if ((num_columns == 2) && (strcmp(row[1], "VIEW") == 0)) > - continue; > + { > + if (!opt_mysql_upgrade) > + continue; > + } > + else > + { > + if (opt_mysql_upgrade) > + continue; Eh? If --mysql-upgrade is specified you skip all tables and only upgrade views? Then the option should absolutely be called --fix-view-algorithm > + } > > end= fix_table_name(end, row[0]); > *end++= ','; > @@ -756,10 +782,12 @@ static int handle_request_for_tables(cha > if (opt_upgrade) end = strmov(end, " FOR UPGRADE"); > break; > case DO_REPAIR: > - op= (opt_write_binlog) ? "REPAIR" : "REPAIR NO_WRITE_TO_BINLOG"; > + op= ((opt_write_binlog || opt_mysql_upgrade) ? > + "REPAIR" : "REPAIR NO_WRITE_TO_BINLOG"); Really? For view upgrades you want it to be written to binlog? This is a very questionable idea. > if (opt_quick) end = strmov(end, " QUICK"); > if (opt_extended) end = strmov(end, " EXTENDED"); > if (opt_frm) end = strmov(end, " USE_FRM"); > + if (opt_mysql_upgrade) end = strmov(end, " FROM MYSQL"); > break; > case DO_ANALYZE: > op= (opt_write_binlog) ? "ANALYZE" : "ANALYZE NO_WRITE_TO_BINLOG"; > @@ -776,14 +804,17 @@ static int handle_request_for_tables(cha > if (opt_all_in_1) > { > /* No backticks here as we added them before */ > - query_length= sprintf(query, "%s TABLE %s %s", op, tables, options); > + query_length= sprintf(query, "%s %s %s %s", op, > + (opt_mysql_upgrade ? "VIEW" : "TABLE"), this is wrong, because mysqlcheck --mysql-upgrade (or, really, mysqcheck --fix-view-algorithm=xxx) should check/repair *both* tables and views. > + tables, options); > table_name= tables; > } > else > { > char *ptr, *org; > > - org= ptr= strmov(strmov(query, op), " TABLE "); > + org= ptr= strmov(strmov(query, op), > + (opt_mysql_upgrade ? " VIEW " : " TABLE ")); > ptr= fix_table_name(ptr, tables); > strmake(table_name_buff, org, min((int) sizeof(table_name_buff)-1, > (int) (ptr - org))); > > === modified file 'mysql-test/r/view.result' > --- a/mysql-test/r/view.result 2014-12-21 18:23:28 +0000 > +++ b/mysql-test/r/view.result 2015-02-09 01:48:28 +0000 ... > +check view v1,v2,v3,v4,v5 FOR UPGRADE; > +Table Op Msg_type Msg_text > +test.v1 check Note view 'test.v1' has no field mariadb server in its .frm file > +test.v1 check status needs repair > +test.v2 check Note view 'test.v2' has no field mariadb server in its .frm file > +test.v2 check status needs repair > +test.v3 check Note view 'test.v3' has no field mariadb server in its .frm file > +test.v3 check status needs repair > +test.v4 check note View text checksum failed > +test.v5 check status OK > +repair view v1,v2,v3,v4,v5 FROM MYSQL; where's the test for "repair view" without FROM MYSQL ? > +Table Op Msg_type Msg_text > +test.v1 repair status view is repaired > +test.v2 repair status view is repaired > +test.v3 repair status view is repaired > +test.v4 repair status view is repaired > +test.v5 repair status OK > > === modified file 'sql/handler.h' > --- a/sql/handler.h 2015-01-13 18:28:03 +0000 > +++ b/sql/handler.h 2015-02-09 01:48:28 +0000 > @@ -42,6 +42,7 @@ > > // the following is for checking tables > > +#define HA_ADMIN_VIEW_REPAIR_IS_DONE 2 > #define HA_ADMIN_ALREADY_DONE 1 > #define HA_ADMIN_OK 0 > #define HA_ADMIN_NOT_IMPLEMENTED -1 > @@ -56,6 +57,7 @@ > #define HA_ADMIN_NEEDS_UPGRADE -10 > #define HA_ADMIN_NEEDS_ALTER -11 > #define HA_ADMIN_NEEDS_CHECK -12 > +#define HA_ADMIN_NEEDS_REPAIR -13 > > /* Bits in table_flags() to show what database can do */ > > === modified file 'sql/share/errmsg-utf8.txt' > --- a/sql/share/errmsg-utf8.txt 2014-05-27 06:45:01 +0000 > +++ b/sql/share/errmsg-utf8.txt 2015-02-09 01:48:28 +0000 > @@ -6565,3 +6565,9 @@ ER_QUERY_EXCEEDED_ROWS_EXAMINED_LIMIT > ER_NO_SUCH_TABLE_IN_ENGINE 42S02 > eng "Table '%-.192s.%-.192s' doesn't exist in engine" > swe "Det finns ingen tabell som heter '%-.192s.%-.192s' i handlern" > +ER_NO_MARIADB_SERVER_FIELD > + eng "view '%-.192s.%-.192s' has no field mariadb server in its .frm file" First, it's "mariadb_version", not "mariadb_server". Second, I'm not sure such a specific condition needs a dedicated error code. And last - we absolutely cannot add new error messages in 5.5, because 10.0 is already GA. I've already written that in my previous review. > +ER_VIEW_REPAIR_IS_DONE > + eng "view is repaired" > +ER_NEEDS_REPAIR > + eng "needs repair" > > === modified file 'sql/sql_admin.cc' > --- a/sql/sql_admin.cc 2014-05-03 16:12:17 +0000 > +++ b/sql/sql_admin.cc 2015-02-09 01:48:28 +0000 > @@ -867,6 +879,22 @@ send_result_message: > fatal_error=1; > break; > } > + case HA_ADMIN_VIEW_REPAIR_IS_DONE: Why did you need that, what's wrong with HA_ADMIN_OK? Btw, I've already written that in my previous review. > + { > + protocol->store(STRING_WITH_LEN("status"), system_charset_info); > + protocol->store(ER(ER_VIEW_REPAIR_IS_DONE), > + strlen(ER(ER_VIEW_REPAIR_IS_DONE)), > + system_charset_info); > + break; > + } > + case HA_ADMIN_NEEDS_REPAIR: Why did you need that, what's wrong with HA_ADMIN_NEEDS_UPGRADE? > + { > + protocol->store(STRING_WITH_LEN("status"), system_charset_info); > + protocol->store(ER(ER_NEEDS_REPAIR), > + strlen(ER(ER_NEEDS_REPAIR)), > + system_charset_info); > + break; > + } > > default: // Probably HA_ADMIN_INTERNAL_ERROR > { > === modified file 'sql/sql_base.cc' > --- a/sql/sql_base.cc 2014-10-31 13:07:29 +0000 > +++ b/sql/sql_base.cc 2015-02-09 01:48:28 +0000 > @@ -3019,12 +3020,17 @@ bool open_table(THD *thd, TABLE_LIST *ta > else if (table_list->open_strategy == TABLE_LIST::OPEN_STUB) > DBUG_RETURN(FALSE); > > + second empty line? > retry_share: > > mysql_mutex_lock(&LOCK_open); > > if (!(share= get_table_share_with_discover(thd, table_list, key, > - key_length, OPEN_VIEW, > + key_length, > + (OPEN_VIEW | > + ((table_list->required_type == > + FRMTYPE_VIEW) ? > + OPEN_VIEW_ONLY : 0)), > &error, > hash_value))) > { > > === modified file 'sql/sql_table.cc' > --- a/sql/sql_table.cc 2015-01-14 11:10:13 +0000 > +++ b/sql/sql_table.cc 2015-02-09 01:48:28 +0000 > @@ -28,7 +28,7 @@ > #include "sql_base.h" // open_table_uncached, lock_table_names > #include "lock.h" // mysql_unlock_tables > #include "strfunc.h" // find_type2, find_set > -#include "sql_view.h" // view_checksum > +#include "sql_view.h" // view_check You've modified only the comment, not the actual C++ code that uses view_checksum in this file. So, either the comment is wrong (view_checksum is not used in this file) and should be removed, or the whole #include is unnecessary. > #include "sql_truncate.h" // regenerate_locked_table > #include "sql_partition.h" // mem_alloc_error, > // generate_partition_syntax, > > === modified file 'sql/sql_view.cc' > --- a/sql/sql_view.cc 2014-12-21 18:23:28 +0000 > +++ b/sql/sql_view.cc 2015-02-09 01:48:28 +0000 > @@ -729,6 +729,26 @@ err: > } > > > +static void make_view_filename(LEX_STRING *dir, char *dir_buff, > + size_t dir_buff_len, > + LEX_STRING *path, char *path_buff, > + size_t path_buff_len, > + LEX_STRING *file, > + TABLE_LIST *view) > +{ > + /* print file name */ > + dir->length= build_table_filename(dir_buff, dir_buff_len - 1, > + view->db, "", "", 0); > + dir->str= dir_buff; > + > + path->length= build_table_filename(path_buff, path_buff_len - 1, > + view->db, view->table_name, reg_ext, 0); > + path->str= path_buff; > + > + file->str= path->str + dir->length; > + file->length= path->length - dir->length; > +} > + > /* number of required parameters for making view */ > static const int required_view_parameters= 15; > > @@ -791,6 +811,81 @@ static File_option view_parameters[]= > static LEX_STRING view_file_type[]= {{(char*) STRING_WITH_LEN("VIEW") }}; > > > +int mariadb_fix_view(THD *thd, TABLE_LIST *view, bool wrong_checksum, > + bool swap_alg) > +{ > + char dir_buff[FN_REFLEN + 1], path_buff[FN_REFLEN + 1]; > + LEX_STRING dir, file, path; > + DBUG_ENTER("mariadb_fix_view"); > + > + if (view->algorithm == VIEW_ALGORITHM_UNDEFINED && > + !wrong_checksum && view->mariadb_version) > + DBUG_RETURN(HA_ADMIN_OK); Eh? Why do you care what view->algorithm is? It doesn't matter whether it's undefined, merge, or temptable - if mariadb_version is set, the algorithm is always correct. > + make_view_filename(&dir, dir_buff, sizeof(dir_buff), > + &path, path_buff, sizeof(path_buff), > + &file, view); > + /* init timestamp */ > + if (!view->timestamp.str) > + view->timestamp.str= view->timestamp_buffer; > + > + /* check old .frm */ > + { > + char path_buff[FN_REFLEN]; > + LEX_STRING path; > + File_parser *parser; > + > + path.str= path_buff; > + fn_format(path_buff, file.str, dir.str, "", MY_UNPACK_FILENAME); > + path.length= strlen(path_buff); > + if (access(path.str, F_OK)) > + DBUG_RETURN(HA_ADMIN_INVALID); > + > + if (!(parser= sql_parse_prepare(&path, thd->mem_root, 0))) > + DBUG_RETURN(HA_ADMIN_INTERNAL_ERROR); > + > + if (!parser->ok() || !is_equal(&view_type, parser->type())) > + DBUG_RETURN(HA_ADMIN_INVALID); > + } > + > + if (swap_alg && view->algorithm != VIEW_ALGORITHM_UNDEFINED) only if mariadb_version is not set. > + { > + DBUG_ASSERT(view->algorithm == VIEW_ALGORITHM_MERGE || > + view->algorithm == VIEW_ALGORITHM_TMPTABLE); > + if (view->algorithm == VIEW_ALGORITHM_MERGE) > + view->algorithm= VIEW_ALGORITHM_TMPTABLE; > + else > + view->algorithm= VIEW_ALGORITHM_MERGE; > + } > + if (wrong_checksum) > + { > + if (view->md5.length != 32) > + { > + if ((view->md5.str= (char *)thd->alloc(32 + 1)) == NULL) > + DBUG_RETURN(HA_ADMIN_FAILED); > + } > + view->calc_md5(view->md5.str); > + view->md5.length= 32; > + } > + view->mariadb_version= MYSQL_VERSION_ID; > + > + if (sql_create_definition_file(&dir, &file, view_file_type, > + (uchar*)view, view_parameters)) > + { > + sql_print_error("View '%-.192s'.'%-.192s': algorithm swap error.", > + view->db, view->table_name); > + DBUG_RETURN(HA_ADMIN_INTERNAL_ERROR); > + } > + sql_print_information("View '%-.192s'.'%-.192s': algorithm swapped to '%s'", > + view->db, view->table_name, > + (view->algorithm == VIEW_ALGORITHM_MERGE)? > + "MERGE":"TEMPTABLE"); > + > + > + DBUG_RETURN(HA_ADMIN_VIEW_REPAIR_IS_DONE); > +} > + > + > /* > Register VIEW (write .frm & process .frm's history backups) > > @@ -927,17 +1022,9 @@ static int mysql_register_view(THD *thd, > } > loop_out: > /* print file name */ > - dir.length= build_table_filename(dir_buff, sizeof(dir_buff) - 1, > - view->db, "", "", 0); > - dir.str= dir_buff; > - > - path.length= build_table_filename(path_buff, sizeof(path_buff) - 1, > - view->db, view->table_name, reg_ext, 0); > - path.str= path_buff; > - > - file.str= path.str + dir.length; > - file.length= path.length - dir.length; > - > + make_view_filename(&dir, dir_buff, sizeof(dir_buff), > + &path, path_buff, sizeof(path_buff), > + &file, view); > /* init timestamp */ > if (!view->timestamp.str) > view->timestamp.str= view->timestamp_buffer; > @@ -1941,6 +2028,63 @@ int view_checksum(THD *thd, TABLE_LIST * > HA_ADMIN_OK); > } > > +/** > + Check view > + > + @param thd thread handle > + @param view view for check > + @param check_opt check options > + > + @retval HA_ADMIN_OK OK > + @retval HA_ADMIN_NOT_IMPLEMENTED it is not VIEW > + @retval HA_ADMIN_WRONG_CHECKSUM check sum is wrong > +*/ > +int view_check(THD *thd, TABLE_LIST *view, HA_CHECK_OPT *check_opt) > +{ > + int res; > + DBUG_ENTER("view_check"); > + if ((res= view_checksum(thd, view)) != HA_ADMIN_OK) > + DBUG_RETURN(res); > + if (((check_opt->sql_flags & TT_FOR_UPGRADE) && > + !view->mariadb_version)) > + { > + push_warning_printf(thd, MYSQL_ERROR::WARN_LEVEL_NOTE, > + ER_NO_MARIADB_SERVER_FIELD, > + ER(ER_NO_MARIADB_SERVER_FIELD), > + view->db, > + view->table_name); > + DBUG_RETURN(HA_ADMIN_NEEDS_REPAIR); > + } > + DBUG_RETURN(HA_ADMIN_OK); > +} > + > + > +/** > + Repair view > + > + @param thd thread handle > + @param view view for check > + @param check_opt check options > + > + @retval HA_ADMIN_OK OK > + @retval HA_ADMIN_NOT_IMPLEMENTED it is not VIEW > + @retval HA_ADMIN_WRONG_CHECKSUM check sum is wrong > +*/ > + > +int view_repair(THD *thd, TABLE_LIST *view, HA_CHECK_OPT *check_opt) > +{ > + DBUG_ENTER("view_repair"); > + bool swap_alg= > + ((check_opt->sql_flags & TT_FROM_MYSQL) && > + (!view->mariadb_version)); > + bool wrong_checksum= view_checksum(thd, view); > + if (wrong_checksum || swap_alg) > + { > + DBUG_RETURN(mariadb_fix_view(thd, view, wrong_checksum, swap_alg)); First, don't call functions from DBUG_RETURN, this produces weird debug traces and somebody will have to fix this later. Always int res= mariadb_fix_view(thd, view, wrong_checksum, swap_alg); DBUG_RETURN(res); Alternatively, feel free to fix dbug macros to support function calls in DBUG_RETURN() :) Second, REPAIR VIEW viewname - without FROM MYSQL - should work too, it should add mariadb_version field without changing the algorithm. > + } > + DBUG_RETURN(HA_ADMIN_OK); > +} > + > /* > rename view > > === modified file 'sql/sql_yacc.yy' > --- a/sql/sql_yacc.yy 2014-11-08 18:54:42 +0000 > +++ b/sql/sql_yacc.yy 2015-02-09 01:48:28 +0000 > @@ -1145,6 +1145,7 @@ bool my_yyoverflow(short **a, YYSTYPE ** > %token MULTIPOINT > %token MULTIPOLYGON > %token MUTEX_SYM > +%token MYSQL_SYM > %token MYSQL_ERRNO_SYM > %token NAMES_SYM /* SQL-2003-N */ > %token NAME_SYM /* SQL-2003-N */ > @@ -7191,11 +7192,16 @@ opt_checksum_type: > ; > > repair: > - REPAIR opt_no_write_to_binlog table_or_tables > + REPAIR opt_no_write_to_binlog table_or_view > { > LEX *lex=Lex; > lex->sql_command = SQLCOM_REPAIR; > lex->no_write_to_binlog= $2; > + if (lex->no_write_to_binlog && lex->only_view) > + { > + my_parse_error(ER(ER_SYNTAX_ERROR)); > + MYSQL_YYABORT; Why? REPAIR NO_WRITE_TO_BINLOG VIEW makes perfect sense to me, why did you want to disallow it? > + } > lex->check_opt.init(); > lex->alter_info.reset(); > /* Will be overriden during execution. */ Regards, Sergei

4 8

[Maria-developers] MDEV-7912 review and related concerns
by Vicențiu Ciorbaru 24 Apr '15

24 Apr '15

Hi, I'd like to report my findings during the investigation of MDEV-7912, ask for a review on my patch and see your opinion on the status of the related code. The patch and all the issues that I am raising are for the 5.5 branch. With the attached patch, the server crash is eliminated. The problem we had was caused by casting a 64bit unsigned int to a 32bit unsigned int, representing a number of bytes to allocate. When the ranges were too big, it caused an overflow and we allocated too little space. On a related note, while looking at the code in the uniques.cc file, I've discovered a lot of potential issues, that are almost guaranteed to fail, if we actually do use more than 4 GB of memory. This holds true especially for Windows, because ulong is 32 bits for a 64 bit compilation, while on Linux, it is 64 bit. I've tried to convert most of the code that made use of uint or ulong or ulonglong for address space indexing (arrays, indices in arrays, memory sizes) to size_t, so that we escape the portability problem when compiling for 32 bit or 64 bit. Unfortunately, the task branches out into various other files that make use of those values. An example of a such a problem is in Unique::Unique constructor, line 90, where init_tree will get passed an overflown parameter (max_in_memory_size). It just so happens that there is a guard within the init_tree function that sets a minimum value, in case we do happen to pass an overflown value. This is however a lucky occurrence. Unique::get_use_cost can output a bad cost value, because get_merge_many_buffs_cost casts the same ulonglong memory size parameter to a ulong. There are many examples like this. I'd like to get your input on this issue, is this something we plan to fix in the near future? Should I embark on the journey of slowly fixing at least parts of it? Also, this issue seems to plague much of the code base, as I get a huge wall of similar size_t -> uint32 warnings across most files. Regards, Vicențiu

2 1

Re: [Maria-developers] [server] MDEV-7130 MASTER_POS_WAIT does not respect timeout when connection_name is specificed (#32)
by Kristian Nielsen 24 Apr '15

24 Apr '15

f4rnham <notifications(a)github.com> writes: > https://mariadb.atlassian.net/browse/MDEV-7130 > MASTER_POS_WAIT(log_name,log_pos,timeout,"connection_name") hangs, does not respect the timeout > > Changed also arg_count check for connection_name to prevent same bug if fifth argument is introduced in future > > Tests can be reduced to just one master_pos_wait select, it may be better since each this select waits one second timeout (except one for non-existing connection, line 23) Right, I cleaned up the test case and integrated it into the existing rpl.rpl_master_pos_wait test. Pushed into 10.0, thanks f4rnham! - Kristian.

1 0

[Maria-developers] TRUE vs true (was: [Commits] ac05f41: postreview fix)
by Oleksandr Byelkin 24 Apr '15

24 Apr '15

Hi, Jan! On 23.04.15 08:38, Jan Lindström wrote: > Sanja, > > Why you use TRUE/FALSE instead of true/false for bool ? Historical reasons. I was told to use TRUE/FALSE long time ago and nobody have told something else. We have no our code style doc so I use what I remember from old MySQL one. [skip]

4 6

[Maria-developers] MDEV-7649 wrong result when comparing utf8 column with an invalid literal
by Alexander Barkov 22 Apr '15

22 Apr '15

Hi Sergei, I tested comparison behaviour for various different situations. Please find the comment with the summary table in the end of: https://mariadb.atlassian.net/browse/MDEV-7649 Currently there are 5 possible reactions on bad bytes on comparison, depending on the collation, presence of an index, and character_set_connection value: - truncate on bad byte, compare only the well-formed prefix (#1) - treat bad bytes as '?' (#7 and #8) - empty set with no warning (#3) - empty set with a warning (#2) - error (#5 and #6) I'm in doubts what to dofor 10.1 and for 5.5. Please suggest. 1. For 10.1 or 10.2 I think it would be nice to make all these cases work exactly the same way. I am not sure which way would be the best. Any ideas? 2. For 5.5 we need to fix the bug with minimal changes. Do you agree? I suggest we fix only #1 and maybe #2. How we fix 5.5 now should probably depend on how we'll fix 10.1, to avoid changing behaviour many times. Please suggest. Thanks.

2 3

[Maria-developers] packaging code - mariadb and jemalloc.
by Daniel Black 22 Apr '15

22 Apr '15

Daniel, or anyone else. Where is the source/build code for the jemalloc build in the mariadb repo (specifically for ubuntu)? Where is the code that triggers making the rpm and deb packages that form the current mariadb and galera releases? My goal is to get these packages whitelisted by travis-ci so container builds of mariadb and running mtr on github pull rquests/branches can occur for everyone without a buildbot. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

2 3

[Maria-developers] documentation
by Daniel Black 22 Apr '15

22 Apr '15

Seems there are a fair few variables and options changed in the course of development. These don't seem to make it to the documentation, especially pages like: https://mariadb.com/kb/en/mariadb/server-system-variables/ https://mariadb.com/kb/en/mariadb/server-status-variables https://mariadb.com/kb/en/mariadb/mysqld-options And their per subsection equivalents. Please make an effort to add/update these pages after a commit. After all, if a user can't see a change is made, or is referring to out of date documentation, then they aren't making use of the effort you put into making a change. If you made the change you are in the best position to describe it. git log sql/sys_vars.cc has quite a number of examples including 2ab49689c689b1c1daeb080ea568c268c5256952 cdb8e6ed38ce641a6cb90a4a93bc5ff15f3ba9f2 a978bdda1e2de35c79e432f026869e163657a263 -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

[Maria-developers] Coverity scanning
by Daniel Black 21 Apr '15

21 Apr '15

Hi, Seems MariaDB has an active Coverity project https://scan.coverity.com/projects/284 ... but it hasn't been looked at for a while. >From my list of bugs I suspect it would of found issues like: * MDEV-7977 * MDEV-7864 * MDEV-4980 In correcting these before release it would of benefited MariaDB by: * Not having SEGV / assertions faults occurring on user machines (even if they where test machines) * hours of time by Elena and me to get a test cases produced for obvious logic bugs -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

2 1

[Maria-developers] MDEV-8024 Remove excessive update_used_tables() calls
by Alexander Barkov 21 Apr '15

21 Apr '15

Hi Sergei, Please review a patch for MDEV-8024. It's needed to as a pre-requisite for "MDEV-7950 Item_func::type() takes 0.26% in OLTP RO" Thanks.

2 1

[Maria-developers] MDEV-8024 Remove excessive update_used_tables() calls
by Alexander Barkov 21 Apr '15

21 Apr '15

Hi Sergei, Please review a patch for MDEV-8024. It's needed to as a pre-requisite for "MDEV-7950 Item_func::type() takes 0.26% in OLTP RO" Thanks.

1 0

[Maria-developers] Need help merging MDEV-7387 from 10.0 to 10.1
by Kristian Nielsen 20 Apr '15

20 Apr '15

Hi Bar, Can you please merge the following patch 10.0 -> 10.1? commit bc902a2bfc46add0708896c07621e3707f66d95f Author: Alexander Barkov <bar(a)mariadb.org> Date: Fri Mar 13 16:12:54 2015 +0400 MDEV-7387 [PATCH] Alter table xxx CHARACTER SET utf8, CONVERT TO CHARACTER SET latin1 should fail Eg. run `git merge bc902a2bfc46add0708896c07621e3707f66d95f` in a 10.1 tree. Or alternatively, tell me how to resolve the below conflict in the merge, which is seen in sql/handler.h, so I can do the merge? (This conflict is blocking me from pushing MDEV-7249, MDEV-5289, MDEV-7668, and MDEV-7802 into 10.1...) - Kristian. ----------------------------------------------------------------------- sql/handler.h: <<<<<<< HEAD void init() { bzero(this, sizeof(*this)); } bool tmp_table() const { return options & HA_LEX_CREATE_TMP_TABLE; } void use_default_db_type(THD *thd) { db_type= tmp_table() ? ha_default_tmp_handlerton(thd) : ha_default_handlerton(thd); } }; /** This struct is passed to handler table routines, e.g. ha_create(). It does not include the "OR REPLACE" and "IF NOT EXISTS" parts, as these parts are handled on the SQL level and are not needed on the handler level. */ struct HA_CREATE_INFO: public Table_scope_and_contents_source_st, public Schema_specification_st { void init() { Table_scope_and_contents_source_st::init(); Schema_specification_st::init(); } }; /** This struct is passed to mysql_create_table() and similar creation functions, as well as to show_create_table(). */ struct Table_specification_st: public HA_CREATE_INFO, public DDL_options_st { // Deep initialization void init() { HA_CREATE_INFO::init(); DDL_options_st::init(); } void init(DDL_options_st::Options options) { HA_CREATE_INFO::init(); DDL_options_st::init(options); } /* Quick initialization, for parser. Most of the HA_CREATE_INFO is left uninitialized. It gets fully initialized in sql_yacc.yy, only when the parser scans a related keyword (e.g. CREATE, ALTER). */ void lex_start() { HA_CREATE_INFO::options= 0; DDL_options_st::init(); } ||||||| merged common ancestors bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; } ======= bool tmp_table() { return options & HA_LEX_CREATE_TMP_TABLE; } bool check_conflicting_charset_declarations(CHARSET_INFO *cs); bool add_table_option_default_charset(CHARSET_INFO *cs) { // cs can be NULL, e.g.: CREATE TABLE t1 (..) CHARACTER SET DEFAULT; if (check_conflicting_charset_declarations(cs)) return true; default_table_charset= cs; used_fields|= HA_CREATE_USED_DEFAULT_CHARSET; return false; } bool add_alter_list_item_convert_to_charset(CHARSET_INFO *cs) { /* cs cannot be NULL, as sql_yacc.yy translates CONVERT TO CHARACTER SET DEFAULT to CONVERT TO CHARACTER SET <character-set-of-the-current-database> TODO: Should't we postpone resolution of DEFAULT until the character set of the table owner database is loaded from its db.opt? */ DBUG_ASSERT(cs); if (check_conflicting_charset_declarations(cs)) return true; table_charset= default_table_charset= cs; used_fields|= (HA_CREATE_USED_CHARSET | HA_CREATE_USED_DEFAULT_CHARSET); return false; } >>>>>>> bc902a2bfc46add0708896c07621e3707f66d95f

3 6

Re: [Maria-developers] MariaDB 10 and MaxScale binlog router
by Kristian Nielsen 20 Apr '15

20 Apr '15

Massimiliano Pinto <massimiliano.pinto(a)mariadb.com> writes: First, Massimiliano, please use the maria-developers@ list for all discussions about development on mariadb and related projects. It is very important to keep all communication in the open and work against mariadb becoming a proprietary SkySQL project rather than an open community project. > we started working with MariaDB 10 master & slaves setup with MaxScale > binlog router (which was developed for MySQL 5.6 without GTID support) > Trying first MariaDB 10 setup we found this statement sent from Slave > to Master (maxsacle here) > > > (1) SET @mariadb_slave_capability=4 Check the MARIA_SLAVE_CAPABILITY_* #defines in sql/log_event.h. When connecting, a slave announces its capabilities (which is basically its version). This tells the master about which events are understood by that version of the slave. The master will check each event if it can be handled by the slave. If not, the event will be converted on-the-fly to something the older slave can understand. For example, a MariaDB 5.5 (or MySQL) slave does not understand GTID events. So a MariaDB 10.0 master will convert the GTID event into a BEGIN query event for slaves that have capability < MARIA_SLAVE_CAPABILITY_GTID (4). If you are accepting connections from a slave, you can do the same conversion. If you do not, then older version slaves might break if they receive events generated by newer version master. You can decide which approach makes sense for your project. If you are connecting to a master, then you need to announce your capability. If you do not, you will be interpreted by the master as having an old version, and newer events (like GTID) will be filtered out and not seen. > We soon got another one statement not handled: > > (2) SELECT binlog_gtid_pos('mst-bin.000001',310) This is used by the slave to obtain the correct GTID position corresponding to the position at which it is starting, when it is connecting in non-GTID mode. When the slave has this information, it becomes easy for the DBA to switch to a new master using GTID: STOP SLAVE; CHANGE MASTER TO master_host='new_master', master_use_gtid=slave_pos; START MASTER; This works even if the slave was not using GTID mode prior to the CHANGE MASTER, thanks to that SELECT binlog_gtid_pos(). > we are not handling it (just return the MaxScale default error message > to the connected client) Then the connected client/slave will assume this is an old master that does not support GTID. So the slave will not know the correct GTID position, and the easy CHANGE MASTER above may not be sufficient. Again, maybe that is fine for you, if you do not plan to support GTID. > We would like to hear your point of view, for (1) > @mariadb_slave_capability, how to handle it? What does it mean? Any > possible issues with different values? > Will this prevent us the use of Binlog router with MariADB 10? > > And for (2), is that ok just to ignore it? Would we get issues? I hope the above answers it (else ask again). Basically, you can ignore (1) and return error in (2), and things should work similar to MariaDB 5.5. But there will be reduced functionality compared to MariaDB 10.0/10.1. - Kristian.

3 5

[Maria-developers] Ubuntu Snappy and MariaDB packaging
by Otto Kekäläinen 19 Apr '15

19 Apr '15

Hello! Cool so see a discussion on the list about how to make the most optimal Docker packaging of MariaDB. I also stumbled across that Ubuntu has this completely novel OS structure called Snappy. Please post in this list if any of you start working on a Ubuntu Snappy version of MariaDB packaging.. Snappy packages are basically just a tar package of the binary and files plus a meta.yml description file: https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/

1 0

[Maria-developers] Oracle April security notices and MariaDB
by Otto Kekäläinen 19 Apr '15

19 Apr '15

Hello! Debian security team is pressing me on the information about which recent Oracle CVEs affect MariaDB and which not. They default to assuming all affect so we need to prove otherwise. The Debian CVE tracker: https://security-tracker.debian.org/tracker/source-package/mariadb-10.0 None of these recent CVEs are listed at the MariaDB.org tracker: https://mariadb.com/kb/en/mariadb/security/ Could somebody please update the MariaDB.org CVE overview page? Thanks! Otto

1 0

Re: [Maria-developers] [Commits] eb47b22: MDEV-7820 Server crashes in in my_strcasecmp_utf8 on subquery in ORDER BY clause of GROUP_CONCAT
by Oleksandr Byelkin 15 Apr '15

15 Apr '15

On 15.04.15 15:26, vicentiu(a)mariadb.org wrote: > revision-id: eb47b226d268e7820a9153672798cf991a8fd0fa > parent(s): cc84ac3be41d9d6ac480d55449d5bf4e324cca10 > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-04-15 16:23:43 +0300 > message: > > MDEV-7820 Server crashes in in my_strcasecmp_utf8 on subquery in ORDER BY clause of GROUP_CONCAT > > It is possible for Item_field to have a NULL field_name. This is true if > the Item_field is created based on a field in a temporary table that has > no name. It is thus necessary to do a null check before attempting a > strcmp. Thank you. OK to push. (do not forget to run full test suite) [skip]

1 0

[Maria-developers] CREATE/ALTER USER syntax in MySQL 5.7.5/5.7.6
by Peter Laursen 13 Apr '15

13 Apr '15

Please read MySQL 5.7 documentation on CREATE USER and ALTER USER syntax: https://dev.mysql.com/doc/refman/5.7/en/create-user.html https://dev.mysql.com/doc/refman/5.7/en/alter-user.html (note before/after version 5.7.5/5.7.6 changes) .. as well as this blog: http://mysqlblog.fivefarmers.com/2015/04/10/improved-alter-user-syntax-supp… "With changes made in MySQL Server 5.7.6, a better distinction is made between privilege-level attributes (those which are managed via GRANT and REVOKE statements) and account-level attributes (those managed using CREATE USER and ALTER USER statements). MySQL has a long history of confusing these – for example, requiring a GRANTcommand to set account resource limits or require SSL. " I think this is a very valid observation and thus also change. Does MariaDB have plans to implement the full CREATE/ALTER USER syntax of MySQL 5.7.5/5.7.6? -- Peter -- Webyog

3 2

[Maria-developers] MDEV-7660 - MySQL WL#6671 "Improve scalability by not using thr_lock.c locks for InnoDB tables"
by Sergey Vojtovich 09 Apr '15

09 Apr '15

Hi Jan, we're trying to adapt MySQL WL#6671 to MariaDB, which is expected to boost concurrent single table workloads. MySQL solution is fully based on MDL. It caused substential changes to MDL, which would be nice to avoid. We'd like to understand if we can achieve the same effect with InnoDB locking. According to WL#6671 InnoDB relied on THR_LOCK in following cases: 1. "To isolate HANDLER READ statements from LOCK TABLES WRITE statements." It is likely not a big problem if we decide to go non-MDL way. 2. "To isolate LOCK TABLES statements that lock tables for write implicitly or for read, both explicitly or implicitly, from concurrent DML statements." That's something that we're looking alternatives for. See below. 3. "Due to coding mistake thr_lock.c lock was necessary to isolate ALTER TABLE IMPORT/DISCARD TABLESPACE under LOCK TABLES from concurrent I_S queries/ open HANDLERs." I agree with this patch, it is merged and pending approval (MDEV-7894). 4. "To indicate that InnoDB tables don't support LOCK TABLES READ LOCAL by upgrading TL_READ lock requested by statement to TL_READ_NO_INSERT." It is likely not a big problem if we decide to go non-MDL way. The question is if InnoDB can do the following with reasonable effort: - LOCK TABLES ... READ - protect table data from concurrent writers - LOCK TABLES ... WRITE - pretect table data from concurrent readers and writers - honor SELECT HIGH_PRIORITY when there's pending LOCK TABLES ... WRITE (do we need this?) - honor LOCK TABLES ... WRITE LOW_PRIORITY when there're concurrent readers (do we need this?) Thanks, Sergey

1 0

[Maria-developers] MDEV-7540 commit.
by Delveri chick 08 Apr '15

08 Apr '15

diff --git a/sql/sql_show.cc b/sql/sql_show.cc index d6d1bd2..5576875 100644 --- a/sql/sql_show.cc +++ b/sql/sql_show.cc @@ -347,6 +347,119 @@ static int fill_spatial_ref_sys(THD *thd, TABLE_LIST *tables, COND *cond) table->field[3]->store(STRING_WITH_LEN(""), cs);/*SRTEXT*/ if (schema_table_store_record(thd, table)) goto exit; + + table->field[0]->store(0, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(0, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN(""), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2041, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2041, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Abidjan 1987 / UTM zone 30N\",GEOGCS[\"Abidjan 1987\",DATUM[\"Abidjan_1987\",SPHEROID[\"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[-124.76,53,466.79,0,0,0,0],AUTHORITY[\"EPSG\",\"6143\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4143\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-3],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2041\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2042, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2042, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Locodjo 1965 / UTM zone 29N\",GEOGCS[\"Locodjo 1965\",DATUM[\"Locodjo_1965\",SPHEROID[\"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[-125,53,467,0,0,0,0],AUTHORITY[\"EPSG\",\"6142\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4142\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-9],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2042\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2043, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2043, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Abidjan 1987 / UTM zone 29N\",GEOGCS[\"Abidjan 1987\",DATUM[\"Abidjan_1987\",SPHEROID[\"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[-124.76,53,466.79,0,0,0,0],AUTHORITY[\"EPSG\",\"6143\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4143\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-9],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2043\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2044, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2044, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hanoi 1972 / Gauss-Kruger zone 18\",GEOGCS[\"Hanoi 1972\",DATUM[\"Hanoi_1972\",SPHEROID[\"Krassowsky 1940\",6378245,298.3,AUTHORITY[\"EPSG\",\"7024\"]],TOWGS84[-17.51,-108.32,-62.39,0,0,0,0],AUTHORITY[\"EPSG\",\"6147\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4147\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",105],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",18500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2044\"],AXIS[\"Y\",EAST],AXIS[\"X\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2045, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2045, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hanoi 1972 / Gauss-Kruger zone 19\",GEOGCS[\"Hanoi 1972\",DATUM[\"Hanoi_1972\",SPHEROID[\"Krassowsky 1940\",6378245,298.3,AUTHORITY[\"EPSG\",\"7024\"]],TOWGS84[-17.51,-108.32,-62.39,0,0,0,0],AUTHORITY[\"EPSG\",\"6147\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4147\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",111],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",19500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2045\"],AXIS[\"Y\",EAST],AXIS[\"X\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2046, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2046, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo15\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",15],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2046\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2047, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2047, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo17\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",17],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2047\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2048, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2048, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo19\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",19],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2048\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2049, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2049, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo21\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",21],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2049\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2050, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2050, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo23\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",23],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2050\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2051, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2051, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo25\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",25],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2051\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2052, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2052, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo27\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",27],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2052\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2053, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2053, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo29\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",29],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2053\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2054, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2054, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo31\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",31],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2054\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2055, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2055, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Hartebeesthoek94 / Lo33\",GEOGCS[\"Hartebeesthoek94\",DATUM[\"Hartebeesthoek94\",SPHEROID[\"WGS 84\",6378137,298.257223563,AUTHORITY[\"EPSG\",\"7030\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6148\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4148\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator_South_Orientated\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",33],PARAMETER[\"scale_factor\",1],PARAMETER[\"false_easting\",0],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2055\"],AXIS[\"Y\",WEST],AXIS[\"X\",SOUTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + result= 0; exit:

1 0

[Maria-developers] MDEV-5536 / MDEV-427 / MDEV-5713 - systemd socket activation, notify
by Daniel Black 07 Apr '15

07 Apr '15

This adds systemd socket activation (listening file descriptors passed on on startup), and systemd notification parts to the core mysql and bits of innodb that may take a bit of time. Scripts to convert from my.cnf settings to a socket activation file are included. support-files/mariadb.service has been included which replaces every bit of mysqld_safe with prebuilt systemd functionality. Systemd can be enabled at compile time and still will support non-system. Even when systemd compile time options are enabled, mysqld will still run in an existing init script or like an existing service. For review: https://github.com/MariaDB/server/pull/26 Thanks Jan for the innodb side of the review so far. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

[Maria-developers] spelling and code comment fixes for review
by Daniel Black 07 Apr '15

07 Apr '15

No code changes. For review: Fixing comments https://github.com/MariaDB/server/pull/24 And spelling in comments: https://github.com/MariaDB/server/pull/36 -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

[Maria-developers] MDEV-7781 Allow {un, }install plugins during bootstrap/skip-grant-tables
by Daniel Black 07 Apr '15

07 Apr '15

For review: https://github.com/MariaDB/server/pull/29 Simple one, this allows plugins to be removed/installed during bootstrap (opt_noacl=true) but still enforces access control in normal operation. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

Re: [Maria-developers] ae2cb44: MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover
by Sergei Golubchik 07 Apr '15

07 Apr '15

Hi, Sergey! On Apr 07, svoj(a)mariadb.org wrote: > revision-id: ae2cb445ea2a51657f1d2581db77db2ecbf70bc1 > parent(s): 7d9e94e2e6c32b906d1d8469e58bc04b8da1c121 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-07 14:59:25 +0400 > message: > > MDEV-7922 - ERROR 1939 (HY000): Engine PERFORMANCE_SCHEMA failed to discover > table > > Performance schema discovery fails if connection has no active database set. > > This happened due to restriction in SQL parser: table name with no database name > is ambiguous in such case. > > Now PFS discovery statements specify database name explicitely. No, I don't like this solution. This is an issue in discovery, there is nothing wrong with how P_S uses it. I'd rather fix it in TABLE_SHARE::init_from_sql_statement_string() by temporarily setting THD::db to this->db (which is a db where the table will be created). Regards, Sergei

2 3

[Maria-developers] Not possible to use FIFO file as a general_log file
by Honza Horak 07 Apr '15

07 Apr '15

This is just a re-sending the issue reported already at https://mariadb.atlassian.net/browse/MDEV-6870 to make it more visible, since there is no respond yet. There was an issue [1] in mysql and mariadb prior to 5.5.40 if socket or fifo files were used as general_log and slow query log files. That issue was fixed by a commit in [2], so currently it is not possible to use other than regular files as log files. I'd like to bring this issue to attention of mariadb developers as well, since our customer is asking for specifically this functionality – to be able to use FIFO file as general_log file. Is it really unacceptable? [1] http://bugs.mysql.com/bug.php?id=67088 [2] http://bazaar.launchpad.net/~mysql/mysql-server/5.5/revision/4688

2 1

[Maria-developers] Passwordless MariaDB root login with auth_socket in Debian continues..
by Otto Kekäläinen 06 Apr '15

06 Apr '15

Hello Daniel B. and others, I decided to write to you via the mailing list so that we are inclusive if somebody wants to join our effort to create a solid passwordless (Debian/Ubuntu) packaging. Thanks Daniel for all the pull requests you've made. Unfortunately there are still some bugs. Now it ends with 'ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded' I have built packages from the latest commit at my Debian packaging repo https://github.com/ottok/mariadb-10.0/commits/master (bac031c9796ebf08c651bc863bda97fcf2cce9c4) so that all of your pull requests regarding this are included. The dev repo addess is 'deb http://labs.seravo.fi/~otto/mariadb-repo/ mariadb-10.0-sid-amd64/' in case you forgot (see https://wiki.debian.org/Teams/MySQL/MariaDB) $ apt-get purge 'mysql-*' 'mariadb-*'; rm -rf /etc/mysql /var/lib/mysql; apt-get clean; apt-get update [..] $ apt-get install mariadb-server [..] Fetched 12.6 MB in 1min 34s (133 kB/s) Preconfiguring packages ... Selecting previously unselected package mysql-common. Preparing to unpack .../mysql-common_5.5.42-1_all.deb ... Unpacking mysql-common (5.5.42-1) ... Selecting previously unselected package libmysqlclient18:amd64. Preparing to unpack .../libmysqlclient18_5.5.42-1_amd64.deb ... Unpacking libmysqlclient18:amd64 (5.5.42-1) ... Selecting previously unselected package mariadb-common. Preparing to unpack .../mariadb-common_10.0.17-1~exp2_all.deb ... Unpacking mariadb-common (10.0.17-1~exp2) ... Selecting previously unselected package mariadb-client-core-10.0. Preparing to unpack .../mariadb-client-core-10.0_10.0.17-1~exp2_amd64.deb ... Unpacking mariadb-client-core-10.0 (10.0.17-1~exp2) ... Selecting previously unselected package mariadb-client-10.0. Preparing to unpack .../mariadb-client-10.0_10.0.17-1~exp2_amd64.deb ... Unpacking mariadb-client-10.0 (10.0.17-1~exp2) ... Selecting previously unselected package mariadb-server-core-10.0. Preparing to unpack .../mariadb-server-core-10.0_10.0.17-1~exp2_amd64.deb ... Unpacking mariadb-server-core-10.0 (10.0.17-1~exp2) ... Processing triggers for man-db (2.7.0.2-3) ... Setting up mysql-common (5.5.42-1) ... Setting up mariadb-common (10.0.17-1~exp2) ... Notice: configure-symlinks trigger could not be called. Please manually make /etc/mysql/my.cnf a symlink that points to mariadb.cnf. Selecting previously unselected package mariadb-server-10.0. Preparing to unpack .../mariadb-server-10.0_10.0.17-1~exp2_amd64.deb ... Unpacking mariadb-server-10.0 (10.0.17-1~exp2) ... Selecting previously unselected package libdbd-mysql-perl. Preparing to unpack .../libdbd-mysql-perl_4.028-2+b1_amd64.deb ... Unpacking libdbd-mysql-perl (4.028-2+b1) ... Selecting previously unselected package mariadb-server. Preparing to unpack .../mariadb-server_10.0.17-1~exp2_all.deb ... Unpacking mariadb-server (10.0.17-1~exp2) ... Processing triggers for man-db (2.7.0.2-3) ... Setting up libmysqlclient18:amd64 (5.5.42-1) ... Setting up mariadb-client-core-10.0 (10.0.17-1~exp2) ... Setting up mariadb-client-10.0 (10.0.17-1~exp2) ... Setting up mariadb-server-core-10.0 (10.0.17-1~exp2) ... Setting up mariadb-server-10.0 (10.0.17-1~exp2) ... + . /usr/share/debconf/confmodule ++ '[' '!' '' ']' ++ PERL_DL_NONLAZY=1 ++ export PERL_DL_NONLAZY ++ '[' '' ']' ++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mariadb-server-10.0.postinst configure '' + . /usr/share/debconf/confmodule ++ '[' '!' 1 ']' ++ '[' -z '' ']' ++ exec ++ '[' '' ']' ++ exec ++ DEBCONF_REDIR=1 ++ export DEBCONF_REDIR + '[' -n '' ']' + export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin:/usr/sbin:/bin:/usr/bin + PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin:/usr/sbin:/bin:/usr/bin + ERR_LOGGER='logger -p daemon.err -t mysqld_safe -i' + set -o pipefail + MYSQL_BOOTSTRAP='/usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam --plugin-load-add=auth_socket' + set +e + invoke stop + '[' -x /usr/sbin/invoke-rc.d ']' + invoke-rc.d mysql stop Stopping MariaDB database server: mysqld. + set -e + case "$1" in + mysql_statedir=/usr/share/mysql + mysql_datadir=/var/lib/mysql + mysql_logdir=/var/log/mysql + mysql_rundir=/var/run/mysqld + mysql_cfgdir=/etc/mysql + mysql_upgradedir=/var/lib/mysql-upgrade + '[' '!' -d /usr/share/mysql -a '!' -L /usr/share/mysql ']' + '[' '!' -d /var/lib/mysql -a '!' -L /var/lib/mysql ']' + '[' '!' -d /var/log/mysql -a '!' -L /var/log/mysql ']' + set +e + chown -R 0:0 /usr/share/mysql + chown -R mysql /var/lib/mysql + chown -R mysql:adm /var/log/mysql + chmod 2750 /var/log/mysql + set -e + db_set mariadb-server/postrm_remove_database false + _db_cmd 'SET mariadb-server/postrm_remove_database' false + _db_internal_IFS=' ' + IFS=' ' + printf '%s\n' 'SET mariadb-server/postrm_remove_database false' + IFS=' ' + IFS=' ' + read -r _db_internal_line + RET='10 mariadb-server/postrm_remove_database doesn'\''t exist' + case ${_db_internal_line%%[ ]*} in + return 10 + true + rm -f '/var/lib/mysql/debian-*.flag' + touch /var/lib/mysql/debian-10.0.flag + set +e + logger -p daemon.err -t mysqld_safe -i + bash /usr/bin/mysql_install_db --rpm --cross-bootstrap --user=mysql --disable-log-bin + set -e + dc=/etc/mysql/debian.cnf + '[' '!' -e /etc/mysql/debian.cnf -o 'grep -sq "^[^#]*user[^#=]*=[^#=]*debian-sys-maint" /etc/mysql/debian.cnf' ']' + '[' '!' -d /etc/mysql ']' + '[' -e /etc/mysql/debian.cnf ']' + oldconf= + umask 066 + cat /dev/null + umask 022 + echo '# Automatically generated for Debian scripts. DO NOT TOUCH!' + echo '[client]' + echo 'host = localhost' + echo 'user = root' + echo 'password = ' + echo 'socket = /var/run/mysqld/mysqld.sock' + echo '[mysql_upgrade]' + echo 'host = localhost' + echo 'user = root' + echo 'password = ' + echo 'socket = /var/run/mysqld/mysqld.sock' + echo 'basedir = /usr' + chown 0:0 /etc/mysql/debian.cnf + chmod 0600 /etc/mysql/debian.cnf ++ /bin/echo -e 'USE mysql;\n' 'SET sql_log_bin=0;\n' 'ALTER TABLE user CHANGE Password Password char(41) character set latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;' + password_column_fix_query='USE mysql; SET sql_log_bin=0; ALTER TABLE user CHANGE Password Password char(41) character set latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;' + echo 'USE mysql; SET sql_log_bin=0; ALTER TABLE user CHANGE Password Password char(41) character set latin1 collate latin1_bin DEFAULT '\'''\'' NOT NULL;' + logger -p daemon.err -t mysqld_safe -i + /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam --plugin-load-add=auth_socket ++ /bin/echo -e 'SET sql_mode='\'''\'', sql_log_bin=0;\n' 'DELETE FROM mysql.user WHERE user='\''debian-sys-maint'\'' AND host='\''localhost'\'';' + replace_query='SET sql_mode='\'''\'', sql_log_bin=0; DELETE FROM mysql.user WHERE user='\''debian-sys-maint'\'' AND host='\''localhost'\'';' ++ /bin/echo -e 'USE mysql;\n' 'SET sql_log_bin=0;\n' 'CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', ' ' dl char(128) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', ' ' PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\'';\n' 'INSTALL PLUGIN unix_socket SONAME '\''auth_socket'\'';\n' + install_plugins='USE mysql; SET sql_log_bin=0; CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', dl char(128) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\''; INSTALL PLUGIN unix_socket SONAME '\''auth_socket'\'';' + set +e + echo 'USE mysql; SET sql_log_bin=0; CREATE TABLE IF NOT EXISTS plugin (name char(64) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', dl char(128) COLLATE utf8_bin NOT NULL DEFAULT '\'''\'', PRIMARY KEY (name)) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='\''MySQL plugins'\''; INSTALL PLUGIN unix_socket SONAME '\''auth_socket'\'';' + logger -p daemon.err -t mysqld_safe -i + /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam --plugin-load-add=auth_socket + set -e + set_mysql_rootpw ++ mktemp + tfile=/tmp/tmp.RyQCYdtKwf + '[' '!' -f /tmp/tmp.RyQCYdtKwf ']' + cat + '[' '' = online ']' + /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam --plugin-load-add=auth_socket + retval=0 + rm -f /tmp/tmp.RyQCYdtKwf + return 0 + '[' -e ']' + rm -f + set +e + echo 'SET sql_mode='\'''\'', sql_log_bin=0; DELETE FROM mysql.user WHERE user='\''debian-sys-maint'\'' AND host='\''localhost'\'';' + logger -p daemon.err -t mysqld_safe -i + /usr/sbin/mysqld --bootstrap --user=mysql --disable-log-bin --skip-grant-tables --default-storage-engine=myisam --plugin-load-add=auth_socket + set -e + '[' configure = configure ']' + test_passwordless_root_login + mysql --no-defaults -u root -h localhost + '[' '' = yes ']' + db_stop + echo STOP + '[' -x /etc/init.d/mysql ']' + update-rc.d mysql defaults 19 21 + invoke-rc.d mysql start Starting MariaDB database server: mysqld. + exit 0 ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded Setting up libdbd-mysql-perl (4.028-2+b1) ... Setting up mariadb-server (10.0.17-1~exp2) ... Processing triggers for libc-bin (2.19-13) ... $ mysql -u root ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded /var/log/mysql/error.log is pasted at http://paste.debian.net/161259/ Please figure out what is still missing and open new pull requests to fix it :) The mariadb-10.0.17-exp1 at the moment in Debian experimental is broken due to inclusion of an early version of this change, so I hope we could get it completed soon so that I don't have to revert the whole passwordless root account feature (which has been requested by many). - Otto

5 19

[Maria-developers] [MDEV-7922] pfs is not cahce definition info at db start (ver 10.1.13)
by 유승훈 06 Apr '15

06 Apr '15

Hello, i did some test about pfs on Mariadb 10.1.13 ver (ubuntu 14.04) So I just add some issue about pfs in mariadb ver 10.1.13 like below jira link simple context : 1) db start 2) just query about pfs => error => but "use pfs" then sql run => no error https://mariadb.atlassian.net/browse/MDEV-7922 Any body some idea about this, reply mail or write on jira. Thanks for your time and attention. Best Regards! SeungHoon. _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

2 2

Re: [Maria-developers] [Commits] Rev 4428: MDEV-6916: Upgrade from MySQL to MariaDB breaks already created views in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-6916-repair_view/
by Daniel Black 04 Apr '15

04 Apr '15

Nice work Oleksandr, Be good to see this committed. I really like the no options bit of mysql_upgrade and the use of is_mysql function. ----- Original Message ----- > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-6916-repair_view/ > > ------------------------------------------------------------ > revno: 4428 > revision-id: sanja(a)askmonty.org-20150213124726-9rn55t3qqx7yzy9q > parent: jplindst(a)mariadb.org-20150210121723-1gxyej083cf1nv8h > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-6916-repair_view > timestamp: Fri 2015-02-13 13:47:26 +0100 > message: > MDEV-6916: Upgrade from MySQL to MariaDB breaks already created views > > CHECK/REPAIR commands and mysql_upgrade support for upgrade from MySQL > server support. > > > [Text File:patch-4428.diff] > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

1 0

[Maria-developers] MDEV-7540 commits.
by Delveri chick 03 Apr '15

03 Apr '15

diff --git a/libmysql/errmsg.c b/libmysql/errmsg.c index 84884f9..abcf3f3 100644 --- a/libmysql/errmsg.c +++ b/libmysql/errmsg.c @@ -31,7 +31,7 @@ "Can't connect to MySQL server on '%-.100s' (%M)", "Can't create TCP/IP socket (%M)", "Unknown MySQL server host '%-.100s' (%d)", - "MySQL server has gone away", + "MySQL server has gone away due to wait_timeout limit reached", "Protocol mismatch; server version = %d, client version = %d", "MySQL client ran out of memory", "Wrong host info", diff --git a/sql/sql_show.cc b/sql/sql_show.cc index c6d73bf..9b2d894 100644 --- a/sql/sql_show.cc +++ b/sql/sql_show.cc @@ -661,6 +661,166 @@ static int fill_spatial_ref_sys(THD *thd, TABLE_LIST *tables, COND *cond) if (schema_table_store_record(thd, table)) goto exit; + table->field[0]->store(2018, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2018, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 9\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-76.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2018\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2019, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2019, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 10\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-79.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2019\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2020, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2020, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 11\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-82.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2020\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2021, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2021, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 12\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-81],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2021\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2022, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2022, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 13\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-84],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2022\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2023, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2023, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 14\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-87],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2023\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2024, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2024, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 15\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-90],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2024\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2025, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2025, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 16\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-93],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2025\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2026, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2026, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 17\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-96],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2026\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2027, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2027, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / UTM zone 15N\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-93],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2027\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2028, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2028, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / UTM zone 16N\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-87],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2028\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2029, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2029, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / UTM zone 17N\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-81],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2029\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2030, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2030, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / UTM zone 18N\",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-75],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2030\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2031, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2031, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / UTM zone 17N\",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-81],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2031\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2032, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2032, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / UTM zone 18N\",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-75],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2032\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2033, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2033, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / UTM zone 19N\",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-69],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2033\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2034, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2034, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / UTM zone 20N\",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-63],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2034\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2035, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2035, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / UTM zone 21N\",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-57],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2035\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2036, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2036, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD83(CSRS98) / New Brunswick Stereo (deprecated)\",GEOGCS[\"NAD83(CSRS98)\",DATUM[\"NAD83_Canadian_Spatial_Reference_System\",SPHEROID[\"GRS 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6140\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9108\"]],AUTHORITY[\"EPSG\",\"4140\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Oblique_Stereographic\"],PARAMETER[\"latitude_of_origin\",46.5],PARAMETER[\"central_meridian\",-66.5],PARAMETER[\"scale_factor\",0.999912],PARAMETER[\"false_easting\",2500000],PARAMETER[\"false_northing\",7500000],AUTHORITY[\"EPSG\",\"2036\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2037, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2037, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD83(CSRS98) / UTM zone 19N (deprecated)\",GEOGCS[\"NAD83(CSRS98)\",DATUM[\"NAD83_Canadian_Spatial_Reference_System\",SPHEROID[\"GRS 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6140\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9108\"]],AUTHORITY[\"EPSG\",\"4140\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-69],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2037\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2038, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2038, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD83(CSRS98) / UTM zone 20N (deprecated)\",GEOGCS[\"NAD83(CSRS98)\",DATUM[\"NAD83_Canadian_Spatial_Reference_System\",SPHEROID[\"GRS 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY[\"EPSG\",\"6140\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.0174532925199433,AUTHORITY[\"EPSG\",\"9108\"]],AUTHORITY[\"EPSG\",\"4140\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-63],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2038\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2039, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2039, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Israel / Israeli TM Grid\",GEOGCS[\"Israel\",DATUM[\"Israel\",SPHEROID[\"GRS 1980\",6378137,298.257222101,AUTHORITY[\"EPSG\",\"7019\"]],TOWGS84[-48,55,52,0,0,0,0],AUTHORITY[\"EPSG\",\"6141\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4141\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",31.73439361111111],PARAMETER[\"central_meridian\",35.20451694444445],PARAMETER[\"scale_factor\",1.0000067],PARAMETER[\"false_easting\",219529.584],PARAMETER[\"false_northing\",626907.39],AUTHORITY[\"EPSG\",\"2039\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2040, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2040, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Locodjo 1965 / UTM zone 30N\",GEOGCS[\"Locodjo 1965\",DATUM[\"Locodjo_1965\",SPHEROID[\"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[-125,53,467,0,0,0,0],AUTHORITY[\"EPSG\",\"6142\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4142\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-3],PARAMETER[\"scale_factor\",0.9996],PARAMETER[\"false_easting\",500000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2040\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; table->field[0]->store(3819, TRUE); /*SRID*/ table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ @@ -674,6 +834,7 @@ static int fill_spatial_ref_sys(THD *thd, TABLE_LIST *tables, COND *cond) if (schema_table_store_record(thd, table)) goto exit; + result= 0; exit:

1 0

[Maria-developers] [GSoC CONC] Non trivial patch
by arlene seuleu 03 Apr '15

03 Apr '15

diff --git a/libmariadb/dbug.c b/libmariadb/dbug.c index fb7c52b..9855f97 100644 --- a/libmariadb/dbug.c +++ b/libmariadb/dbug.c @@ -428,9 +428,9 @@ static void read_lock_stack(CODE_STATE *cs) */ static void unlock_stack(CODE_STATE *cs) { - if (cs->stack == &init_settings) + if (cs->stack == &init_settings && --(cs->m_read_lock_count) == 0) { - if (--(cs->m_read_lock_count) == 0) + pthread_mutex_unlock(&THR_LOCK_init_settings); } }

2 1

Re: [Maria-developers] [GSoC 2015] patch.
by Oleksandr Byelkin 03 Apr '15

03 Apr '15

Hi! On 03.04.15 12:25, arlene seuleu wrote: > Hi Byelkin > I just did it for consistency with the other storage macros to to > facilitate readability. I do not see any consistency except hiding cause why other macro was written. Please do not make changes in sake of changes. The same about formating, if you do not make some meaningful changes in that like do not change formating of it even if it is wrong.

1 0

[Maria-developers] More explicit Error message
by Blessing Atie 03 Apr '15

03 Apr '15

diff --git a/libmysql/errmsg.c b/libmysql/errmsg.c index 84884f9..abcf3f3 100644 --- a/libmysql/errmsg.c +++ b/libmysql/errmsg.c @@ -31,7 +31,7 @@ "Can't connect to MySQL server on '%-.100s' (%M)", "Can't create TCP/IP socket (%M)", "Unknown MySQL server host '%-.100s' (%d)", - "MySQL server has gone away", + "MySQL server has gone away due to wait_timeout limit reached", "Protocol mismatch; server version = %d, client version = %d", "MySQL client ran out of memory", "Wrong host info",

1 0

[Maria-developers] Patch
by Blessing Atie 03 Apr '15

03 Apr '15

Added generic build instructions from KB to INSTALL-SOURCE diff --git a/INSTALL-SOURCE b/INSTALL-SOURCE index 32cfa97..809d69b 100644 --- a/INSTALL-SOURCE +++ b/INSTALL-SOURCE @@ -1,3 +1,86 @@ -Instructions for building MariaDB can be found at: +The instructions in this file will help you compile MariaDB from source. Links to more complete instructions for specific platforms can be found at https://kb.askmonty.org/en/compiling-mariadb-from-source/ +First, get a copy of the MariaDB source. + +Next, prepare your system to be able to compile the source. + +If you don't want to run MariaDB as yourself, then you should create a mysql user. The example below uses this user. + +MariaDB starting with 5.5 + +Using cmake + +MariaDB 5.5 and above is compiled using cmake. You can configure your build simply by running cmake without any special options, like +cmake . +but if you want it to be configured exactly as we do for our releases, use +cmake . -DBUILD_CONFIG=mysql_release +All cmake configuration options for MariaDB can be displayed with: +cmake . -LH +To build and install MariaDB after running cmake use +make +sudo make install +If the commands above fail, you can enable more compilation information by doing: +make VERBOSE=1 +MariaDB until 5.3 +Building MariaDB with the BUILD scripts +The easiest way of building MariaDB would be to use the appropriate BUILD script that matches your configuration. For example: +cd $maria-source-dir # ex: ~/repos/maria/trunk + +BUILD/compile-pentium64-max # Build for intel/amd 64 bit with all options +BUILD/compile-pentium-max # Build for 32 bit pentum with all options + +BUILD/compile-pentium64-debug-max # Build for intel/amd 64 bit with debugging +BUILD/compile-pentium64-valgrind-max # Build for testing with valgrind + +There are many different BUILD scripts which cover many different configurations and processor architectures. +To see what a build scripts does, you can run it with the --print option. +After building MariaDB with a BUILD script, install MariaDB with: +sudo make install +Building MariaDB Manually +If there is no appropriate script, you can also execute the build commands directly: + +cd $maria-source-dir # ex: ~/repos/maria/trunk +BUILD/autorun.sh +./configure +make +sudo make install +Max builds configure line +The following configure line is the one we used to use in the -max builds (which includes all features we think are relevant). This is also the configure line we use with most of our binary builds: + +./configure --prefix=/usr/local/mysql --enable-assembler \ + --with-extra-charsets=complex --enable-thread-safe-client --with-big-tables \ + --with-plugin-maria --with-aria-tmp-tables --without-plugin-innodb_plugin \ + --with-mysqld-ldflags=-static --with-client-ldflags=-static --with-readline \ + --with-ssl --with-plugins=max-no-ndb --with-embedded-server --with-libevent \ + --with-mysqld-ldflags=-all-static --with-client-ldflags=-all-static \ + --with-zlib-dir=bundled --enable-local-infile + +For a full list of options, you can do: + +./configure --help + +Starting MariaDB for the first time +After installing MariaDB (using sudo make install), but prior to starting MariaDB for the first time, one should: + +ensure the directory where you installed MariaDB is owned by the mysql user (if the user doesn't exist, you'll need to create it) +run the mysql_install_db script to generate the needed system tables +Here is an example: + +# The following assumes that the 'mysql' user exists and that we installed MariaDB + +# in /usr/local/mysql +chown -R mysql /usr/local/mysql/ +scripts/mysql_install_db --user=mysql +/usr/local/mysql/bin/mysqld_safe --user=mysql & + + +Testing MariaDB + +If you want to test your compiled MariaDB, you can do either of: + +make test +or + +cd mysql-test ; ./mysql-test-run --force +Each of the above are run from the source directory. There is no need to 'sudo make install' MariaDB prior to running them. \ No newline at end of file

1 0

[Maria-developers] [GSoC 2015] patch.
by arlene seuleu 03 Apr '15

03 Apr '15

diff --git a/mysys/ma_dyncol.c b/mysys/ma_dyncol.c index a7a048a..0789350 100644 --- a/mysys/ma_dyncol.c +++ b/mysys/ma_dyncol.c @@ -329,20 +329,20 @@ static my_bool type_and_offset_store_num(uchar *place, size_t offset_size, case 1: if (offset >= 0x1f) /* all 1 value is reserved */ return TRUE; - place[0]= (uchar)val; + int1store(place,val); break; case 2: - if (offset >= 0x1fff) /* all 1 value is reserved */ + if (offset >= 0x1fff) /* all 2 values are reserved */ return TRUE; int2store(place, val); break; case 3: - if (offset >= 0x1fffff) /* all 1 value is reserved */ + if (offset >= 0x1fffff) /* all 3 values are reserved */ return TRUE; int3store(place, val); break; case 4: - if (offset >= 0x1fffffff) /* all 1 value is reserved */ + if (offset >= 0x1fffffff) /* all 4 values are reserved */ return TRUE; int4store(place, val); break; diff --git a/mysys/mysys_priv.h b/mysys/mysys_priv.h index 4ea6d08..962dc5a 100644 --- a/mysys/mysys_priv.h +++ b/mysys/mysys_priv.h @@ -16,6 +16,10 @@ #include <my_global.h> #include <my_sys.h> +#define int1store(T,A) do { uint def_temp= (uint) (A) ;\ + *((uchar*) (T))= (uchar)(def_temp);\ + }while(0) + #ifdef USE_SYSTEM_WRAPPERS #include "system_wrappers.h" #endif

2 1

Re: [Maria-developers] [Commits] fc31f6d: MDEV-7833:ANALYZE FORMAT=JSON and Range checked for each record
by Sergey Petrunia 02 Apr '15

02 Apr '15

Hi Sanja, Please find review comments below. On Thu, Apr 02, 2015 at 06:19:41PM +0200, sanja(a)mariadb.com wrote: > revision-id: fc31f6d95720b4b946b8b68c816026d65831f347 > parent(s): 01d7da6785284383b2c04f2d4474feccebb0bb6f > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-04-02 18:19:33 +0200 > message: > > MDEV-7833:ANALYZE FORMAT=JSON and Range checked for each record > > --- > mysql-test/r/analyze_format_json.result | 62 +++++++++++++++++++++++++++++ > mysql-test/t/analyze_format_json.test | 30 ++++++++++++++ > sql/sql_explain.cc | 26 +++++++++++-- > sql/sql_explain.h | 12 +++++- > sql/sql_select.cc | 69 ++++++++++++++++++++++++++++++--- > sql/sql_select.h | 7 +++- > 6 files changed, 195 insertions(+), 11 deletions(-) > > diff --git a/mysql-test/r/analyze_format_json.result b/mysql-test/r/analyze_format_json.result > index 9022d8c..b3ef075 100644 > --- a/mysql-test/r/analyze_format_json.result > +++ b/mysql-test/r/analyze_format_json.result > @@ -264,3 +264,65 @@ ANALYZE > } > } > drop table t1; > +# > +# MDEV-7833:ANALYZE FORMAT=JSON and Range checked for each record > +# > +create table t3(a int); > +insert into t3 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); > +create table t4(a int); > +insert into t4 select A.a + B.a* 10 + C.a * 100 from t3 A, t3 B, t3 C; > +create table t1 (lb1 int, rb1 int, lb2 int, rb2 int, c1 int, c2 int); > +insert into t1 values (1,2,10,20,15,15); > +insert into t1 values (3,5,10,20,15,15); > +insert into t1 values (10,20,10,20,15,15); > +insert into t1 values (10,20,1,2,15,15); > +insert into t1 values (10,20,10,20,1,3); > +create table t2 (key1 int, key2 int, key3 int, key4 int, col1 int, > +key(key1), key(key2), key(key3), key(key4)); > +insert into t2 select a,a,a,a,a from t3; > +insert into t2 select 15,15,15,15,15 from t4; > +analyze format=json > +select * from t1, t2 where (t2.key1 between t1.lb1 and t1.rb1) and > +(t2.key2 between t1.lb2 and t1.rb2) and > +(t2.key3=t1.c1 OR t2.key4=t1.c2); > +ANALYZE > +{ > + "query_block": { > + "select_id": 1, > + "r_loops": 1, > + "r_total_time_ms": "REPLACED", > + "table": { > + "table_name": "t1", > + "access_type": "ALL", > + "r_loops": 1, > + "rows": 5, > + "r_rows": 5, > + "r_total_time_ms": "REPLACED", > + "filtered": 100, > + "r_filtered": 100 > + }, > + "range-checked-for-each-record": { > + "keys": ["key1", "key2", "key3", "key4"], > + "r_keys_none": 1, > + "r_keys_index_merge": 1, > + "r_keys": { > + "key1": 2, > + "key2": 1, > + "key3": 0, > + "key4": 0 > + }, It seems wrong to have multiple r_XXX elements. I think, having one will be better. How about: r_keys: { "none": 1, ## Maybe, change to "full_table_scan" ? (btw can it be a full index scan instead I wonder?) "index_merge": nnn, "range" : { "key1" : nnn, "key2" : nnn, "key3" : nnn } } Let's discuss it. > + "table": { > + "table_name": "t2", > + "access_type": "ALL", > + "possible_keys": ["key1", "key2", "key3", "key4"], > + "r_loops": 5, > + "rows": 1010, > + "r_rows": 203.8, > + "r_total_time_ms": "REPLACED", > + "filtered": 100, > + "r_filtered": 98.135 > + } > + } > + } > +} > +drop table t1,t2,t3,t4; > diff --git a/mysql-test/t/analyze_format_json.test b/mysql-test/t/analyze_format_json.test > index 64bafd7..0ae9d4f 100644 > --- a/mysql-test/t/analyze_format_json.test > +++ b/mysql-test/t/analyze_format_json.test > @@ -75,3 +75,33 @@ disconnect con1; > connection default; > drop table t1; > > + > +--echo # > +--echo # MDEV-7833:ANALYZE FORMAT=JSON and Range checked for each record > +--echo # > +create table t3(a int); > +insert into t3 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); > + > +create table t4(a int); > +insert into t4 select A.a + B.a* 10 + C.a * 100 from t3 A, t3 B, t3 C; > + > +create table t1 (lb1 int, rb1 int, lb2 int, rb2 int, c1 int, c2 int); > + > +insert into t1 values (1,2,10,20,15,15); > +insert into t1 values (3,5,10,20,15,15); > +insert into t1 values (10,20,10,20,15,15); > +insert into t1 values (10,20,1,2,15,15); > +insert into t1 values (10,20,10,20,1,3); > + > +create table t2 (key1 int, key2 int, key3 int, key4 int, col1 int, > + key(key1), key(key2), key(key3), key(key4)); > +insert into t2 select a,a,a,a,a from t3; > +insert into t2 select 15,15,15,15,15 from t4; > + > +--replace_regex /"r_total_time_ms": [0-9]*[.]?[0-9]*/"r_total_time_ms": "REPLACED"/ > +analyze format=json > +select * from t1, t2 where (t2.key1 between t1.lb1 and t1.rb1) and > + (t2.key2 between t1.lb2 and t1.rb2) and > + (t2.key3=t1.c1 OR t2.key4=t1.c2); > + > +drop table t1,t2,t3,t4; > diff --git a/sql/sql_explain.cc b/sql/sql_explain.cc > index 9d82f4f..edbc2bf 100644 > --- a/sql/sql_explain.cc > +++ b/sql/sql_explain.cc > @@ -1076,15 +1076,15 @@ int Explain_table_access::print_explain(select_result_sink *output, uint8 explai > } > > Please add a comment: @return ptr - pointer to the added string NULL - out of memory error Does it make sense to change the return type to 'const char*' ? > -bool String_list::append_str(MEM_ROOT *mem_root, const char *str) > +char *String_list::append_str(MEM_ROOT *mem_root, const char *str) > { > size_t len= strlen(str); > char *cp; > if (!(cp = (char*)alloc_root(mem_root, len+1))) > - return 1; > + return NULL; > memcpy(cp, str, len+1); > push_back(cp); > - return 0; > + return cp; > } > > > @@ -1209,6 +1209,26 @@ void Explain_table_access::print_explain_json(Explain_query *query, > { > writer->add_member("range-checked-for-each-record").start_object(); > add_json_keyset(writer, "keys", &possible_keys); > + if (is_analyze) > + { > + writer->add_member("r_keys_none").add_ll(range_checked_fer->none); > + writer->add_member("r_keys_index_merge").add_ll(range_checked_fer-> > + index_merge); > + if (range_checked_fer->keys_stat) > + { > + writer->add_member("r_keys").start_object(); > + for (uint i= 0; i < range_checked_fer->keys; i++) > + { > + if (range_checked_fer->keys_stat_names[i]) > + { > + writer->add_member(range_checked_fer-> > + keys_stat_names[i]).add_ll(range_checked_fer-> > + keys_stat[i]); > + } > + } > + writer->end_object(); > + } > + } If we move this code into Range_checked_fer::print_json(), will it be possible to make its members private? > } > > if (full_scan_on_null_key) > diff --git a/sql/sql_explain.h b/sql/sql_explain.h > index e3b41ee..f86886d 100644 > --- a/sql/sql_explain.h > +++ b/sql/sql_explain.h > @@ -54,7 +54,7 @@ it into the slow query log. > class String_list: public List<char> > { > public: > - bool append_str(MEM_ROOT *mem_root, const char *str); > + char *append_str(MEM_ROOT *mem_root, const char *str); > }; > > class Json_writer; > @@ -627,6 +627,16 @@ class Explain_range_checked_fer : public Sql_alloc > public: > String_list key_set; > key_map keys_map; > + > + ha_rows none, index_merge; 'none' looks weird. Would a 'full_scan' be better. > + ha_rows *keys_stat; > + char **keys_stat_names; > + uint keys; This needs to be documented. > + > + Explain_range_checked_fer() > + :Sql_alloc(), none(0), index_merge(0), > + keys_stat(0), keys_stat_names(0), keys(0) > + {} > }; > > /* > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index 5c3e116..4eb3d81 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -11398,6 +11398,7 @@ void JOIN_TAB::cleanup() > table->reginfo.join_tab= 0; > } > end_read_record(&read_record); > + explain_plan= 0; It's a pointer, right? Please change s/0/NULL/ > DBUG_VOID_RETURN; > } > > @@ -18762,9 +18763,30 @@ test_if_quick_select(JOIN_TAB *tab) > > delete tab->select->quick; > tab->select->quick=0; > - return tab->select->test_quick_select(tab->join->thd, tab->keys, > - (table_map) 0, HA_POS_ERROR, 0, > - FALSE, /*remove where parts*/FALSE); > + int res= tab->select->test_quick_select(tab->join->thd, tab->keys, > + (table_map) 0, HA_POS_ERROR, 0, > + FALSE, /*remove where parts*/FALSE); > + if (tab->explain_plan && tab->explain_plan->range_checked_fer) > + { > + if (tab->select->quick) > + { > + QUICK_SELECT_I *quick= tab->select->quick; > + if (quick->index == MAX_KEY) > + tab->explain_plan->range_checked_fer->index_merge++; > + else > + { > + DBUG_ASSERT(quick->index < tab->explain_plan->range_checked_fer->keys); > + DBUG_ASSERT(tab->explain_plan->range_checked_fer->keys_stat); > + DBUG_ASSERT(tab->explain_plan->range_checked_fer->keys_stat_names); > + DBUG_ASSERT(tab->explain_plan->range_checked_fer->keys_stat_names[ > + quick->index]); > + tab->explain_plan->range_checked_fer->keys_stat[quick->index]++; > + } > + } > + else > + tab->explain_plan->range_checked_fer->none++; > + } > + return res; I think it's bad that join execution code becomes littered with details about how things are stored in the Explain data structures. Can you add a set of methods to range_checked_fer: count_full_scan(); count_index_merge(); count_range_scan(); and then only call these methods from here? > } > > > @@ -23360,6 +23382,32 @@ int append_possible_keys(MEM_ROOT *alloc, String_list &list, TABLE *table, > return 0; > } > What does this function do? AFAIU it does two things: - copies indexes from possible_keys into a String_list. - allocates an empty array of ha_rows(). The set of data structures used by Range_checked_fer is quite peculiar. This function is only useful for Range_checked_fer. Do you think it would make sense to made this a method of Range_checked_fer? > +int append_possible_keys_stat(MEM_ROOT *alloc, String_list &list, > + ha_rows **stat, char ***names, > + TABLE *table, key_map possible_keys) > +{ > + uint j; > + multi_alloc_root(alloc, stat, sizeof(ha_rows) * table->s->keys, > + names, sizeof(char *) * table->s->keys, NULL); > + if ((!(*stat)) || (!(*names))) > + { > + (*stat)= NULL; (*names)= NULL; > + return 1; > + } > + bzero(*stat, sizeof(ha_rows) * table->s->keys); > + for (j= 0; j < table->s->keys; j++) > + { > + if (possible_keys.is_set(j)) > + { > + char *nm= list.append_str(alloc, table->key_info[j].name); > + (*names)[j]= nm; > + } > + else > + (*names)[j]= NULL; > + } > + return 0; > +} > + > /* > TODO: this function is only applicable for the first non-const optimization > join tab. > @@ -23400,6 +23448,8 @@ void JOIN_TAB::save_explain_data(Explain_table_access *eta, table_map prefix_tab > quick_type= -1; > QUICK_SELECT_I *quick= NULL; > > + > + explain_plan= eta; > eta->key.clear(); > eta->quick_info= NULL; > > @@ -23663,9 +23713,16 @@ void JOIN_TAB::save_explain_data(Explain_table_access *eta, table_map prefix_tab > { > eta->push_extra(ET_RANGE_CHECKED_FOR_EACH_RECORD); > eta->range_checked_fer= new (thd->mem_root) Explain_range_checked_fer; > - eta->range_checked_fer->keys_map= tab->keys; > - append_possible_keys(thd->mem_root, eta->range_checked_fer->key_set, > - table, tab->keys); > + if (eta->range_checked_fer) > + { > + eta->range_checked_fer->keys_map= tab->keys; > + eta->range_checked_fer->keys= table->s->keys; > + append_possible_keys_stat(thd->mem_root, > + eta->range_checked_fer->key_set, > + &eta->range_checked_fer->keys_stat, > + &eta->range_checked_fer->keys_stat_names, > + table, tab->keys); > + } > } > else if (tab->select->cond || > (tab->cache_select && tab->cache_select->cond)) > diff --git a/sql/sql_select.h b/sql/sql_select.h > index 0557e32..ef92690 100644 > --- a/sql/sql_select.h > +++ b/sql/sql_select.h > @@ -362,7 +362,12 @@ typedef struct st_join_table { > SJ_TMP_TABLE *check_weed_out_table; > /* for EXPLAIN only: */ > SJ_TMP_TABLE *first_weedout_table; > - > + > + /** > + reference to saved plan and execution statistics > + */ > + Explain_table_access *explain_plan; > + > /* > If set, means we should stop join enumeration after we've got the first > match and return to the specified join tab. May point to BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] [GSoC] MDEV-4674 Port InnoDB memcached interface to MariaDB
by Piotr Jurkiewicz 02 Apr '15

02 Apr '15

Hello. My name is Piotr Jurkiewicz. I am a last year MSc student at AGH University of Science and Technology in Krakow, Poland. I already contributed to MySQL InnoDB Memcached plugin. I know it well, from user and developer points of view. I have been using MySQL InnoDB Memcached plugin since half year in a production system I administrate at my university. However, I must admit that quality of this plugin is rather poor. I have run several times into bugs, from the simple ones, like incorrect results of arithmetic operations, to the serious, like crashes of the whole MySQL process. I reported some of these bugs to Oracle and contributed patches fixing them [1] [2]. However, the more I was diving into the plugin code, the more I was realizing that the problem is not only buggy code and insufficient testing. The core mistakes had been made at the very beginning, when plugin architecture was set up. The most prominent result of these mistakes is lack of access security. After connecting to Memcached port, a user has access to all databases and tables exported by the plugin. Fixing this would require complete remodeling of plugin architecture and the way users configure and use it. This is not possible in MySQL, as it would break existing deployments. Therefore, I was very excited, when I saw that porting of InnoDB Memcached plugin is among MariaDB proposed GSoC ideas. This gives a possibility to build the plugin in a proper way. During the last months I have been thinking a lot how this plugin should be structured. I think I worked out a clear concept of that. With the financing from Google I will be able to dedicate sufficient amount of time for its implementation, what should result in fully featured, secure and robust Memcached plugin for MariaDB. You can review current version of my proposal in the Google Melange system: https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015… As for now, it is only visible for MariaDB organization members, who are registered in Melange system. On March 27th, after student application deadline, I will make it visible for non-registered users as well and send its copy to this list. I am waiting for your remarks and hints. [1]: http://bugs.mysql.com/bug.php?id=74874 [2]: http://bugs.mysql.com/bug.php?id=75864 Piotr

4 8

Re: [Maria-developers] [server] Mdev 7802 binlog groupcommit stats (#30)
by Kristian Nielsen 02 Apr '15

02 Apr '15

Daniel Black <notifications(a)github.com> writes: Thanks for your patch. I agree that these kinds of status information could be useful. But I have some parts that are not clear, and I want you to think about the questions below and answer with your thoughts. This is to make sure you understand yourself the issue in detail; to help me understand it; and in some cases maybe some changes should be made. > The following global status variables where added: > * binlog_group_commit_reason_count > * binlog_group_commit_reason_usec So, these names seem a bit odd. Neither "count" nor "usec" makes much sense as a reason for something to happen. "_timeout" would be a better reason that "_usec", but I am not sure of a better name for "_count". The good thing about these names of course is that they match the corresponding --binlog-commit-wait-* option. What do you think of something like binlog_commit_trigger_count binlog_commit_trigger_timeout instead ? > * binlog_group_commit_reason_transaction > * binlog_group_commit_reason_immediate > binlog_group_commit_reason_transaction is a result of ordered > transaction that need to occur in the same order on the slave and can't > be parallelised. > > binlog_group_commit_reason_immediate is caused to prevent stalls with > row locks as described in log.cc:binlog_report_wait_for. This immediate > count is also counted a second time in binlog_group_commit_reason_transaction. Please re-read that explanation, and consider: do you think an average user/DBA will fully understand what these status variables mean? Honestly, I am wondering if you can even yourself explain exactly what the difference is between the two :-). Can you give two simple examples of transactions, one example of which will increment the _transaction status variable and one of which will increment the _immediate? Do you think the distinction between the two is useful for the user? If not, maybe just have a single status variable, like binlog_commit_trigger_lock_wait for example? > Overall binlog_group_commits = binlog_group_commit_reason_count + > binlog_group_commit_reason_usec + binlog_group_commit_reason_transaction Is this also true if --binlog-commit-wait-count=0? If so, what will the values of the different status variables be in this case? Now, to the patches. > + { > + if (++count >= opt_binlog_commit_wait_count) > + { > + group_commit_reason_count++; > + return; > + } > + if (unlikely(e->thd->has_waiter)) > + { > + group_commit_reason_transaction++; > return; > + } > + } So this increments the global status variables directly, I think? How does the thread locking work? Is it possible for a reader to see a corrupt value (eg. one word of the old value and one word of the new) on 32-bit platform? How is this handled for other similar status variables? It would not be good if we had to take some LOCK_status or something inside the critical group commit code. With respect to the test cases: Can you please comment yourself on the different places where you added output of the status variables, and explain why this output will always be the same, no matter how threads are scheduled on the machine running the test? (This is the critical part of most tests related to replication; because of the inherently multi-threaded nature of such tests, a lot of care is needed to make sure the test will not produce different output on different test runs depending on the speed of the host or how threads are scheduled on a loaded machine). - Kristian.

2 2

[Maria-developers] [MDEV-7540] Information Schema SPATIAL_REF_SYS contents don't match the expected contents
by Delveri chick 02 Apr '15

02 Apr '15

diff --git a/sql/sql_show.cc b/sql/sql_show.cc index dce2f7b..c6d73bf 100644 --- a/sql/sql_show.cc +++ b/sql/sql_show.cc @@ -355,6 +355,324 @@ static int fill_spatial_ref_sys(THD *thd, TABLE_LIST *tables, COND *cond) if (schema_table_store_record(thd, table)) goto exit; + table->field[0]->store(1, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("SR-ORG"), cs); /*AUTH_NAME*/ + table->field[2]->store(1, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"unnamed\",\ + GEOGCS[\"GRS 1980(IUGG, 1980)\",DATUM[\"unknown\",SPHEROID[\"GRS80\",\ + 6378137,298.257222101]],PRIMEM[\"Greenwich\",0],UNIT[\"degree\",\ + 0.0174532925199433]],PROJECTION[\"Lambert_Conformal_Conic_2SP\"],\ + PARAMETER[\"standard_parallel_1\",42.6833319],PARAMETER[\"standard_parallel_2\",\ + 41.71666666666667],PARAMETER[\"latitude_of_origin\",41],PARAMETER[\"central_meridian\",\ + -71.5],PARAMETER[\"false_easting\",200000],PARAMETER[\"false_northing\",\ + 750000],UNIT[\"Meter\",1]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2000, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2000, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Anguilla 1957 / British West Indies Grid\ + \",GEOGCS[\"Anguilla 1957\",DATUM[\"Anguilla_1957\",SPHEROID[\ + \"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\ + \"]],AUTHORITY[\"EPSG\",\"6600\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\ + \"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\ + \"]],AUTHORITY[\"EPSG\",\"4600\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2000\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2001, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2001, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Antigua 1943 / British West Indies Grid\ + \",GEOGCS[\"Antigua 1943\",DATUM[\"Antigua_1943\",SPHEROID[\ + \"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\ + \"]],AUTHORITY[\"EPSG\",\"6601\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\ + \"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\ + \"]],AUTHORITY[\"EPSG\",\"4601\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-62],PARAMETER[\"scale_factor\ + \",0.9995],PARAMETER[\"false_easting\",400000],PARAMETER[\"false_northing\ + \",0],AUTHORITY[\"EPSG\",\"2001\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\ + \",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2002, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2002, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Dominica 1945 / British West Indies Grid\ + \",GEOGCS[\"Dominica 1945\",DATUM[\"Dominica_1945\",SPHEROID[\ + \"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\ + \"]],TOWGS84[725,685,536,0,0,0,0],AUTHORITY[\"EPSG\",\"6602\"]],PRIMEM[\ + \"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\ + \",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\ + \"4602\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\ + \"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\ + \"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2002\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2003, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2003, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Grenada 1953 / British West Indies Grid\ + \",GEOGCS[\"Grenada 1953\",DATUM[\"Grenada_1953\",SPHEROID[\"Clarke 1880 (RGS)\ + \",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[72,213.7,93,0,0,0,0],AUTHORITY[\ + \"EPSG\",\"6603\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\ + \"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\ + \",\"4603\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\ + \"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\ + \"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2003\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2004, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2004, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"Montserrat 1958 / British West Indies Grid\ + \",GEOGCS[\"Montserrat 1958\",DATUM[\"Montserrat_1958\",SPHEROID[\ + \"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\ + \"]],TOWGS84[174,359,365,0,0,0,0],AUTHORITY[\"EPSG\",\"6604\"]],PRIMEM[\ + \"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\ + \"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4604\"]],UNIT[\"metre\ + \",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\ + \"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\ + \",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\"false_easting\ + \",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\"2004\ + \"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2005, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2005, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"St. Kitts 1955 / British West Indies Grid\ + \",GEOGCS[\"St. Kitts 1955\",DATUM[\"St_Kitts_1955\",SPHEROID[\"Clarke 1880 (RGS)\ + \",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],AUTHORITY[\"EPSG\",\ + \"6605\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\ + \"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\ + \"EPSG\",\"4605\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\ + \"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\ + \"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2005\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2006, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2006, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"St. Lucia 1955 / British West Indies Grid\ + \",GEOGCS[\"St. Lucia 1955\",DATUM[\"St_Lucia_1955\",SPHEROID[\"Clarke 1880 (RGS)\ + \",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\"]],TOWGS84[-149,128,296,0,0,0,0],AUTHORITY[\ + \"EPSG\",\"6606\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\ + \"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\ + \"]],AUTHORITY[\"EPSG\",\"4606\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2006\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2007, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2007, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"St. Vincent 45 / British West Indies Grid\ + \",GEOGCS[\"St. Vincent 1945\",DATUM[\"St_Vincent_1945\",SPHEROID[\ + \"Clarke 1880 (RGS)\",6378249.145,293.465,AUTHORITY[\"EPSG\",\"7012\ + \"]],TOWGS84[195.671,332.517,274.607,0,0,0,0],AUTHORITY[\"EPSG\",\"6607\ + \"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\ + \",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\ + \"4607\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\ + \"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\ + \"central_meridian\",-62],PARAMETER[\"scale_factor\",0.9995],PARAMETER[\ + \"false_easting\",400000],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2007\"],AXIS[\"Easting\",EAST],AXIS[\"Northing\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2008, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2008, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 2\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\ + \"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\ + \",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\ + \"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\ + \"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\ + \"central_meridian\",-55.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\ + \"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2008\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2009, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2009, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 3\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\ + \"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\ + \"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\ + \"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\ + \"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-58.5],PARAMETER[\ + \"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\ + \",0],AUTHORITY[\"EPSG\",\"2009\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2010, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2010, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 4\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\ + \"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\ + \",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\ + \"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\ + \"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-61.5],PARAMETER[\ + \"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\ + \"false_northing\",0],AUTHORITY[\"EPSG\",\"2010\"],AXIS[\"X\",EAST],AXIS[\ + \"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2011, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2011, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 5\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\ + \",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\ + \",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\ + \"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\ + \",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\ + \"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\ + \"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-64.5],PARAMETER[\ + \"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\ + \"false_northing\",0],AUTHORITY[\"EPSG\",\"2011\"],AXIS[\"X\",EAST],AXIS[\ + \"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2012, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2012, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 6\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\ + \",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\ + \",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\ + \"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\ + \",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\ + \"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-67.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\ + \"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\",\ + \"2012\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2013, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2013, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 7\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\ + \",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\ + \",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\ + \"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\ + \",\"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\ + \"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-70.5],PARAMETER[\"scale_factor\",0.9999],PARAMETER[\ + \"false_easting\",304800],PARAMETER[\"false_northing\",0],AUTHORITY[\"EPSG\ + \",\"2013\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2014, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2014, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 8\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\ + \"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\ + \"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\ + \"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-73.5],PARAMETER[\"scale_factor\ + \",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\ + \",0],AUTHORITY[\"EPSG\",\"2014\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2015, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2015, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 9\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\"]],AUTHORITY[\ + \"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\"8901\"]],UNIT[\"degree\ + \",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\"]],AUTHORITY[\"EPSG\",\ + \"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\"9001\"]],PROJECTION[\"Transverse_Mercator\ + \"],PARAMETER[\"latitude_of_origin\",0],PARAMETER[\"central_meridian\",-76.5],PARAMETER[\ + \"scale_factor\",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\ + \"false_northing\",0],AUTHORITY[\"EPSG\",\"2015\"],AXIS[\"X\",EAST],AXIS[\ + \"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2016, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2016, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(CGQ77) / SCoPQ zone 10\ + \",GEOGCS[\"NAD27(CGQ77)\",DATUM[\"North_American_Datum_1927_CGQ77\ + \",SPHEROID[\"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\ + \",\"7008\"]],AUTHORITY[\"EPSG\",\"6609\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\ + \"EPSG\",\"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\ + \"9122\"]],AUTHORITY[\"EPSG\",\"4609\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-79.5],PARAMETER[\"scale_factor\ + \",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\ + \",0],AUTHORITY[\"EPSG\",\"2016\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + table->field[0]->store(2017, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(2017, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("PROJCS[\"NAD27(76) / MTM zone 8\ + \",GEOGCS[\"NAD27(76)\",DATUM[\"North_American_Datum_1927_1976\",SPHEROID[\ + \"Clarke 1866\",6378206.4,294.9786982138982,AUTHORITY[\"EPSG\",\"7008\ + \"]],AUTHORITY[\"EPSG\",\"6608\"]],PRIMEM[\"Greenwich\",0,AUTHORITY[\"EPSG\",\ + \"8901\"]],UNIT[\"degree\",0.01745329251994328,AUTHORITY[\"EPSG\",\"9122\ + \"]],AUTHORITY[\"EPSG\",\"4608\"]],UNIT[\"metre\",1,AUTHORITY[\"EPSG\",\ + \"9001\"]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\ + \",0],PARAMETER[\"central_meridian\",-73.5],PARAMETER[\"scale_factor\ + \",0.9999],PARAMETER[\"false_easting\",304800],PARAMETER[\"false_northing\ + \",0],AUTHORITY[\"EPSG\",\"2017\"],AXIS[\"X\",EAST],AXIS[\"Y\",NORTH]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; + + + table->field[0]->store(3819, TRUE); /*SRID*/ + table->field[1]->store(STRING_WITH_LEN("EPSG"), cs); /*AUTH_NAME*/ + table->field[2]->store(3819, TRUE); /*AUTH_SRID*/ + table->field[3]->store(STRING_WITH_LEN("GEOGCS[\"HD1909\",DATUM[\"Hungarian Datum 1909\",\ + SPHEROID[\"Bessel 1841\",6377397.155,299.1528128,AUTHORITY[\"EPSG\",\"7004\"]],\ + TOWGS84[595.48,121.69,515.35,4.115,2.9383,-0.853,-0.7029504596901044],\ + AUTHORITY[\"EPSG\",\"1024\"]],PRIMEM[\"Greenwich\",0.0,AUTHORITY[\"EPSG\",\ + \"8901\"]],UNIT[\"degree\",0.017453292519943295],AXIS[\"Geodetic latitude\",\ + NORTH],AXIS[\"Geodetic longitude\",EAST],AUTHORITY[\"EPSG\",\"3819\"]]"), cs);/*SRTEXT*/ + if (schema_table_store_record(thd, table)) + goto exit; result= 0;

1 0

Re: [Maria-developers] 622611b: MDEV-7012: SET STATEMENT character_set_client, character_set_connection, character_set_filesystem, collation_connection have no effect
by Sergei Golubchik 02 Apr '15

02 Apr '15

Hi, Sanja! On Mar 17, sanja(a)mariadb.com wrote: > revision-id: 622611bc6a9371803f349d8cf4de6538ebbcdb37 > parent(s): a21ef88d2a358904f0cdf9cadc701cb263b5e317 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-03-17 14:40:25 +0100 > message: > > MDEV-7012: SET STATEMENT character_set_client, character_set_connection, character_set_filesystem, collation_connection have no effect > > Variables of simple SET STATEMENT set just after assigning > > (changes in test suite result checked) While it's a neat innovative trick, I don't think we should execute statements (and setting variables is executing) from the parser. It's very fragile and breaks in various corner cases, resulting in unfixable gotchas. For example, how would the following work: CREATE PROCEDURE foo BEGIN SET STATEMENT CHARACTER_SET_CONNECTION = latin5 FOR SELECT 'фи'; END So, I'd prefer a simple rule "first - the statement is parsed, then it is executed", meaning no effects from the statement execution can affect how it was parsed. Regards, Sergei

1 0

[Maria-developers] Please review MDEV-7284 INDEX: CREATE OR REPLACE
by Alexander Barkov 02 Apr '15

02 Apr '15

Hi Sergei, Please review a patch for MDEV-7284 Thanks.

2 1

Re: [Maria-developers] [Commits] 135d926d3: MDEV-6714 mysqldump slow with tables in big databases
by Sergei Golubchik 02 Apr '15

02 Apr '15

Hi, Vicentiu! Just one minor change, see the comment in get_actual_table_name(). After that please push. Well done, thanks! Regards, Sergei On Mar 19, vicentiu(a)mariadb.org wrote: > revision-id: 135d926d347443672626f1e655709fd5bf6dec80 > parent(s): 197afb413fcc9f06b5e5e6ef41ce980d108b354f > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-03-19 15:16:22 +0200 > message: > > MDEV-6714 mysqldump slow with tables in big databases > > mysqldump now attempts to make use of the INFORMATION_SCHEMA tables. > If the table name is not found with a case sensitive search, it > fallbacks to a case insensitive search. > > --- > client/mysqldump.c | 90 ++++++++++++++++++++++++++++++++++++++++++------------ > 1 file changed, 71 insertions(+), 19 deletions(-) > > diff --git a/client/mysqldump.c b/client/mysqldump.c > index 2da4ce6..c265217 100644 > --- a/client/mysqldump.c > +++ b/client/mysqldump.c > @@ -3341,8 +3341,10 @@ static int dump_triggers_for_table(char *table_name, char *db_name) > /* Get list of triggers. */ > > my_snprintf(query_buff, sizeof(query_buff), > - "SHOW TRIGGERS LIKE %s", > - quote_for_like(table_name, name_buff)); > + "SELECT TRIGGER_NAME FROM INFORMATION_SCHEMA.TRIGGERS " > + "WHERE EVENT_OBJECT_SCHEMA = DATABASE() AND " > + "EVENT_OBJECT_TABLE = \"%s\"", > + table_name); You still need to quote table_name, it might contain a double quote inside. quote_names() almost does what you need, but you don't need a check for MASK_ANSI_QUOTES. So you might either create a quote_names_helper, again, or simply create a new function for this, it's just a few lines anyway. UPD: There are other similar places in mysqldump where it doesn't quote table names, e.g. in get_table_structure(), for show_fields_stmt query. So, please create a separate bug report for this and then it'll fix everything at once. > if (mysql_query_with_error_report(mysql, &show_triggers_rs, query_buff)) > goto done; > @@ -4695,29 +4697,37 @@ static my_bool dump_all_views_in_db(char *database) > > > /* > - get_actual_table_name -- executes a SHOW TABLES LIKE '%s' to get the actual > - table name from the server for the table name given on the command line. > - we do this because the table name given on the command line may be a > - different case (e.g. T1 vs t1) > - > - RETURN > - pointer to the table name > - 0 if error > + See get_actual_table_name. Used to retrieve the correct table name > + from the database schema. > */ > - > -static char *get_actual_table_name(const char *old_table_name, MEM_ROOT *root) > +static char *get_actual_table_name_helper(const char *old_table_name, > + my_bool case_sensitive, > + MEM_ROOT *root) > { > char *name= 0; > MYSQL_RES *table_res; > MYSQL_ROW row; > char query[50 + 2*NAME_LEN]; > char show_name_buff[FN_REFLEN]; > - DBUG_ENTER("get_actual_table_name"); > + DBUG_ENTER("get_actual_table_name_helper"); > > /* Check memory for quote_for_like() */ > DBUG_ASSERT(2*sizeof(old_table_name) < sizeof(show_name_buff)); > - my_snprintf(query, sizeof(query), "SHOW TABLES LIKE %s", > - quote_for_like(old_table_name, show_name_buff)); > + > + if (case_sensitive) > + { > + DBUG_PRINT("info", ("case sensitive search")); > + my_snprintf(query, sizeof(query), > + "SELECT table_name FROM INFORMATION_SCHEMA.TABLES " > + "WHERE table_schema = DATABASE() AND table_name = \"%s\"", > + old_table_name); > + } > + else > + { > + DBUG_PRINT("info", ("case insensitive search")); > + my_snprintf(query, sizeof(query), "SHOW TABLES LIKE %s", > + quote_for_like(old_table_name, show_name_buff)); > + } > > if (mysql_query_with_error_report(mysql, 0, query)) > return NullS; > @@ -4742,6 +4752,46 @@ static char *get_actual_table_name(const char *old_table_name, MEM_ROOT *root) > DBUG_RETURN(name); > } > > +/* > + get_actual_table_name -- executes a SELECT .. FROM I_S.tables to check > + if the table name given on the command line matches the one in the database. > + If the table is not found, it falls back to a slower SHOW TABLES LIKE '%s' to > + get the actual table name from the server. > + > + We do this because the table name given on the command line may be a > + different case (e.g. T1 vs t1), but checking this takes a long time > + when there are many tables present. > + > + RETURN > + pointer to the table name > + 0 if error > +*/ > + > +static char *get_actual_table_name(const char *old_table_name, MEM_ROOT *root) > +{ > + char *name= 0; > + MYSQL_RES *table_res; > + MYSQL_ROW row; > + int lower_case_table_names; > + const char *show_var_query = "SHOW VARIABLES LIKE 'lower_case_table_names'"; > + DBUG_ENTER("get_actual_table_name"); > + > + if (mysql_query_with_error_report(mysql, &table_res, show_var_query)) > + return NullS; I'd prefer if you do it only once, not for every get_actual_table_name() call. > + > + if ((row= mysql_fetch_row(table_res))) > + { > + lower_case_table_names= atoi(row[1]); > + mysql_free_result(table_res); > + } > + > + name= get_actual_table_name_helper(old_table_name, TRUE, root); > + if (!name && !lower_case_table_names) > + name= get_actual_table_name_helper(old_table_name, FALSE, root); > + DBUG_RETURN(name); > +} > + > + > > static int dump_selected_tables(char *db, char **table_names, int tables) > {

1 0

[Maria-developers] Problem of accessing pfs table in maria version 10.1.3
by 김경남 01 Apr '15

01 Apr '15

Hi, I'm developing monitoring tool in daemon plugin I'm tyring to access pfs table via low level interface not using sql. (see below) ------------------------------------------------------------------------ ------------- ..... tables.init_one_table(STRING_WITH_LEN("performance_schema"), STRING_WITH_LEN("events_statements_current"), "events_statements_current", TL_READ); bool result = open_and_lock_tables(ctx->thd, &tables, FALSE, MYSQL_LOCK_IGNORE_TIMEOUT); if (result) { sql_print_error("monm plugin error: Can't open the %s.%s table.",dbname,tblname); } ..... /* read routine */ ------------------------------------------------------------ In open_and_lock_table function, I hava a error. I found the reason of this error by debugging. In table_cache.cc, open_table_def() requires .frm file as a table definition. but above version 10.1.3, there is no frm file for pfs table as I know. right? Let me know a correct way to get data from pfs table not using sql. Regards, Kyungnam. _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

1 0

[Maria-developers] Using THD instance in a daemon thread.
by 김경남 31 Mar '15

31 Mar '15

Hi, I'm writing mariadb daemon type plugin. I hava a question. In a daemon thread, I want to use THD instance. for example, ------------------------------------------------------------------------ ----------- class THD; static int plugin_init() { ... pthread_create(&id,&attr,my_func,...); } void my_func(void* p) { THD* thd = new THD; thd->thread_stack= (char*) &thd; thd->store_globals(); tables.init_one_table("performance_schema", 18, "events_statements_current", 25, "events_statements_current", TL_READ); open_and_lock_tables(thd, &tables, FALSE, MYSQL_LOCK_IGNORE_TIMEOUT); ... } ------------------------------------------------------------------------ -------------------- but In my_func(), new THD cause error. I guess thread problem. So I moved that code to plugin_init() for test as below -------------------------------------------------------------- class THD; static int plugin_init() { ... pthread_create(&id,&attr,my_func,...); THD* thd = new THD; thd->thread_stack= (char*) &thd; thd->store_globals(); tables.init_one_table("performance_schema", 18, "events_statements_current", 25, "events_statements_current", TL_READ); open_and_lock_tables(thd, &tables, FALSE, MYSQL_LOCK_IGNORE_TIMEOUT); ... } ------------------------------------------------------------------------ ----- and then there is no problem. but I need a daemon thread. I think that the reason of this error is assertion of thread. So I changed my code as below. ------------------------------------------------------------------------ --------- class THD; THD* thd; static int plugin_init() { ... pthread_create(&id,&attr,my_func,...); THD* thd = new THD; // moved here from my_func() for avoiding error. } void my_func(void* p) { thd->thread_stack= (char*) &thd; thd->store_globals(); tables.init_one_table("performance_schema", 18, "events_statements_current", 25, "events_statements_current", TL_READ); open_and_lock_tables(thd, &tables, FALSE, MYSQL_LOCK_IGNORE_TIMEOUT); ... } ------------------------------------------------------------------------ ----------------- At this time, thd->store_globals() cause error. In sql_class.cc , mysys_var->id= thread_id cause error because mysys_var is null. Let me know how to use THD instance in daemon thread. Regards, Kyungnam 김경남 부책임연구원 솔루션사업본부 정보기술 연구원 신기술개발팀 02-2099-6177 / 010-2208-3006 _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

2 1

[Maria-developers] ok to change FixVersion to 10.1 for MDEV-7649 wrong result when comparing utf8 column with an invalid literal
by Alexander Barkov 31 Mar '15

31 Mar '15

Hi Sergei, Do you think it's ok to change FixVersion for MDEV-7649 to 10.1? It requires some changes in sql_lex.cc, sql_yacc.yy and needs a new Item_string-alike Item to handle such malformed strings properly. Too big change to 10.0 or 5.5.

2 1

[Maria-developers] TokuDB test suite failures when building at Launchpad
by Otto Kekäläinen 29 Mar '15

29 Mar '15

Hello! Are here any TokuDB devs who could help me debug why TokuDB does repeatedly fails to pass build suite tests when built on Launchpad.net? I repeatedly get these test failures when running MariaDB builds on Launchpad: rpl-tokudb.tokudb_innodb_xa_crash tokudb_bugs.mdev4533 tokudb.simple_join_tokudb_innodb tokudb.truncate_txn_rollback_innodb tokudb_bugs.5733_innodb The build run log can be viewed at https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.0/+builds?bu… and it links to the individual build logs. All amd64 builds fail while all i386 (where TokuDB is disabled) pass OK. Sounds very much like a TokuDB-related issue. Or could the problem be something else and the TokuDB tests are just the first victim? Example of a recent log: https://launchpadlibrarian.net/196425361/buildlog_ubuntu-vivid-amd64.mariad… One example of the test outputs: *** rpl-tokudb.tokudb_innodb_xa_crash 'mix,xtradb' [ fail ] Test ended at 2015-02-02 22:29:06 CURRENT_TEST: rpl-tokudb.tokudb_innodb_xa_crash Failed to start mysqld.1 mysqltest failed but provided no output - saving '/build/buildd/mariadb-10.0-10.0.16/builddir/mysql-test/var/log/rpl-tokudb.tokudb_innodb_xa_crash-mix,xtradb/' to '/build/buildd/mariadb-10.0-10.0.16/builddir/mysql-test/var/log/rpl-tokudb.tokudb_innodb_xa_crash-mix,xtradb/' - found 'core' (1/5) Trying 'dbx' to get a backtrace Trying 'gdb' to get a backtrace Compressed file /build/buildd/mariadb-10.0-10.0.16/builddir/mysql-test/var/log/rpl-tokudb.tokudb_innodb_xa_crash-mix,xtradb/mysqld.1/data/core ***Warnings generated in error logs during shutdown after running tests: rpl-tokudb.tokudb_innodb_xa_crash 150202 22:29:05 [ERROR] mysqld got signal 11 ; Attempting backtrace. You can use the following information to find out 150202 22:29:05 [ERROR] mysqld got signal 11 ; Attempting backtrace. You can use the following information to find out ***

4 15

[Maria-developers] GSoC Proposal Submitted.
by arlene seuleu 28 Mar '15

28 Mar '15

Hello everyone, I am Arlene Flavie, currently a Sofeware Engineering student and I have submitted a proposal for the CONC-125 task: "Imporrt and Export popular data formats from and to dynamic columns". I had been in contact with the mentor and other mariadb developpers(serg, danblack) whose help was immense in writing my proposal. However I am still available to discuss it here and on #maria as Arlene. Hoping to get feedback from the community soon. Best Regards Arlene Flavie

1 0

[Maria-developers] MySQL 5.7.6 adds "statement digest" independent of P_S
by Peter Laursen 27 Mar '15

27 Mar '15

.. as well as configurable digest length. http://mysqlserverteam.com/mysql-statement-digests-configurable-max-lengths/ http://mysqlserverteam.com/mysql-statement-digests/ Will this be ported to MariaDB? IMO this is/was one of the (not so many) useful things in P_S. And better now. -- Peter -- Webyog

1 0

[Maria-developers] In daemon plugin, THD problem.
by 김경남 27 Mar '15

27 Mar '15

Hi, Sergei! I'm writing daemon plugin . I hava a problem and don't find soultion yet. There is my code as below. ex)plugin.cc ----------------------------------------------------- pthread_handler_t monm_monitor(void *p) { .... THD* thd; thd = new THD; thd->thread_stack= (char*) &thd; tables.init_one_table("performance_schema", 18, "events_statements_current", 25, "events_statements_current", TL_READ); open_and_lock_tables(thd, &tables, FALSE, MYSQL_LOCK_IGNORE_TIMEOUT); ..... } static int monm_plugin_init(void *p __attribute__ ((unused))) { ... pthread_create(&mon_thread, &attr, monm_monitor,(void *) ctx)!= 0) .... } ------------------------------------------------------------- In monm_monitor function, THD* thd cause server crash. so I examined coredump. #6 0x0000000000598752 in THD::THD (this=0x7f9b64000930, is_wsrep_applier=false) at /home/windfree/workspace/ws-mariadb/maria-mon/sql/sql_class.cc:1015 I don't know the reason of crash. What I just want to is read events_statements_current's row by using internal interface in a daemon plugin. Is there a another way ? let me know the solution. Regards, Kyungnam. 김경남 부책임연구원 솔루션사업본부 정보기술 연구원 신기술개발팀 02-2099-6177 / 010-2208-3006 _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

2 2

Re: [Maria-developers] [Org FW][RE]Re: init_one_table problem.
by sergei 25 Mar '15

25 Mar '15

Hi, 김경남! On Mar 25, 김경남 wrote: > Hi, Sergei ! > > below contents is my previous question . > > After sending email , I see the debug message.like below. > > "Assertion thd == current_thd() failed." > > My code contains. > > THD thd = new THD; > > so I changed my code as > > THD thd = current_thd; > > but thd is null. > > how to I fix it? Note that sql_acl.cc (for example) has THD *thd=new THD; thd->thread_stack= (char*) &thd; thd->store_globals(); All three lines are important. In particular, THD::store_global sets current_thd. Regards, Sergei

1 0

[Maria-developers] init_one_table problem.
by 김경남 25 Mar '15

25 Mar '15

Hi ~ I hava a problem below code in my plugin. ---------------------------------- TABLE_LIST tables; TABLE table; tables.init_one_table(C_STRING_WITH_LEN("performance_schema"),C_STRING_W ITH_LEN("events_statements_current"), events_statements_current, TL_READ); if(table = tables.table) {...} ------------------------------------------------------- During debugging, I found that tables.table is null. Is there a additional task before my code? Regards, Kyungnam. 김경남 부책임연구원 솔루션사업본부 정보기술 연구원 신기술개발팀 02-2099-6177 / 010-2208-3006 _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

2 1

Re: [Maria-developers] [RE]Re: I wonder what elements add to CMakeLists.txt
by Sergei Golubchik 25 Mar '15

25 Mar '15

Hi, kyungnam! On Mar 24, kyungnam wrote: > > I hava a question. > > I'm developing mariadb plugin . and I make a development environment > according to below url. > > https://mariadb.com/blog/compiling-debugging-mariadband-mysql-eclipse-scrat… > > I seperate source folder and package folder. > > During developing, I hava a trouble with too much build time. > > for example, after I edit sql_parse.cc (add one or two lines) , I run > command "make" under source root folder. > > The build time takes about 5 ~ 10min. and then I run command "make > package". That time takes about 10min. > > At first, I copied libmysqld.so.18 to package folder. but had no > effect. finally I run command "make package" and reinstall mariadb. > > I think I'm doing wrong things. > > please let me know the efficient way to build and debug. I'm not using Eclipse, so I'm afraid I cannot help you with that. If you just modify sql_parse.cc, the compilation should be fast and only that file has to be recompiled (and few binaries re-linked). If you see a lot of files recompiled than either you modified more than sql_parse.cc or your IDE is doing that for you. Make package needs to copy many files so it's a bit slow if you do it very often. I don't - unless I specifically work on packaging I run "make package" very rarely. You don't have to compile libmysqld every time. Run cmake -DWITH_EMBEDDED_SERVER=OFF in your build directory. Regards, Sergei

1 0

[Maria-developers] Merge 10.0 -> 10.1
by Kristian Nielsen 25 Mar '15

25 Mar '15

I have some patches in 10.0 that have not yet been merged to 10.1. Today I attempted the merge, but there were a few conflicts that I was not sure how to handle. Some charset-related functions touching fields that had moved to another struct, some error handling functions in XtraDB with new extra arguments. In case someone else does the merge, I just wanted to point out one conflict in one of my patches in the 10.0 -> 10.1 merge, as the correct resolution is not obvious: <<<<<<< HEAD if (mysql_bin_log.is_open()) return true; ||||||| merged common ancestors ======= if (mysql_bin_log.is_open() && opt_binlog_commit_wait_count > 0) return true; >>>>>>> origin/10.0 The correct conflict resolution here is to leave the code as it was in 10.1: if (mysql_bin_log.is_open()) return true; Or I can do the complete 10.0 -> 10.1 merge if necessary, figuring out the other conflicts, but I did not want to do that without coordinating, to avoid duplicating efforts. - Kristian.

2 1

[Maria-developers] GSoC 2015: Table functions (a.k.a UDF returning arrays / result set) MDEV-5199
by Diwas Joshi 25 Mar '15

25 Mar '15

Hello, I am Diwas, a Masters' student at IIIT Hyderabad, India. I am interested to work on "Table functions (a.k.a UDF returning arrays / result set)". I have downloaded and built MariaDB 10.1 source code from github. I started going through the code. I realized UDF's for scalar values is already implemented in the code, so i began to analyze from there. I got myself acquainted with the query work-flow. I believe the work will be similar to create_function from sql_udf.cc for some part. I understand that I'll need some real storage mechanism for executing the functions in queries so I'll need to use the handler class for this. Please tell me how much of the project I have understood correctly and if I am on the right lines here and how can i proceed towards writing my proposal for this project. regards Diwas Joshi

2 1

[Maria-developers] Port InnoDB memcached interface to MariaDB (GSOC 2015)
by Aalekh Nigam 24 Mar '15

24 Mar '15

Hello, I am Aalekh Nigam, 3rd Year Undergraduate student at JIIT Noida, India. I would like to propose my participation for Port InnoDB MemcacheInterface to MariaDB (https://mariadb.atlassian.net/browse/MDEV-4674) as GSOC 2015 Student. For the purpose of security following is the approach I have planned to accomplish for this project: The plugin will contain a xtradb_memcached.sql table for configuation option, these configuration options will also contain a username, password , tcp/udp address, port no. as column objects which will help us authenticate the connection for a specified user, thus on authentication the server would fetch corresponding tcp/udp address and port to connect with the memcached server. Hence this will not just prove an improvement to the existing mysql plugin but also provide a better security to the database. Nextly after connecting with a memcached server, our database will act as a NoSql system providing rapid user query transaction. Also please follow my proposal here: https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015… Waiting for your comments regarding the approach. ---Aalekh

1 1

Re: [Maria-developers] I wonder what elements add to CMakeLists.txt
by 김경남 24 Mar '15

24 Mar '15

Hi, Sergei! Thanks for your advice and I agree with you. Accoring to your advice, It's not a good plan to pass some data to my plugin agent from sql_parser.cc because it needs to compile mariadb server. So I hava a another concept. Instead of put some code to sql_parse.cc, plugin collects a some data like below sample conceptual code. I_List_iterator<THD> it(threads); while ((tmp_thd=it++)) { if ((tmp_thd->get_command() == COM_QUERY) ||(tmp_thd->get_command() == COM_STMT_EXECUTE) ) continue; char* sql = tmp_thd->query(); if(sql) { ... send_data(); } } In this case, I though that it doesn't need to compile maria server, but it need to recompile whenever structure of THD is changed. Can you accept that? Otherwise, if i hardcode directly into the server, can I contribute this community ? Additionally, you asked me about what information I want to collect. I want to collect data like below. * events_statements_current * events_stages_current * events_waits_current * events_statements_summary_by_digest These data easily collected by sql . but it's hard to collect by access memory.(THD or something else.) I wonder if it is possible to collect these data without using pfs (or psi) data structure. If it is possible, Is THD class is entry point or something else? If you don't mind, please let me know the best way to collect these data. Dear, kyungnam. ps: my email address changed from gmail to my company's mail address. ------------------------------------------------------------------------ ---- From: Sergei Golubchik <serg(a)mariadb.org> Date: 2015-03-24 0:11 GMT+09:00 Subject: Re: [Maria-developers] I wonder what elements add to CMakeLists.txt To: kyung nam Kim <knamkim(a)gmail.com> Cc: maria-developers(a)lists.launchpad.net Hi, kyung! On Mar 23, kyung nam Kim wrote: > Hi, Sergei! > Thanks for your reply. > You asked me about information which I want to send to my plugin. > I have a plan to develop monitoring tool for mariadb. > I want to develop a agent as a mariadb plugin. > Agent collect data from sql_parse.cc (I' don't know exactly where more > infomation about performance .) and sends that data to APM (Application > Performance Monitoring) Server. and Users use databoard to see that data > via APM server. > > We have already have a APM Server, Dashboard and many kinds of agent. (for > server, was). I want to add agent for mariaDB and contribute this community > if possible. Right. That's exactly why I ask. We cannot accept your plugin and it'll be of little use to the community (not "of no use", it'll be used, but less than it could've been) if one would need to modify and recompile MariaDB to use your plugin. If you'd like, let's try to figure out whether you can collect your infomation without patching the server. So what data do you need, exactly? > Your advice is right. It's easier my header file to sql folder. > But When I want to develop my agent as a plugin type, I meet error as > follows. > ============================================ > [ 98%] Built target mysqlserver > Linking CXX shared library libmysqld.so > ../../sql_parse.cc:linenum: undefined reference to 'Mymon::Mymon()' > ../../sql_parse.cc:linenum: undefined reference to 'Mymon::putData(THD* > thd); Of course. Because you want sql_parse.cc to call your plugin, your plugin *always must be in the server*. You cannot have it as a separate shared object. To do that, add the MANDATORY keyword to your MYSQL_ADD_PLUGIN() declaration in CMakeLists.txt Regards, Sergei _____ 상기 메시지와 첨부화일 내에는 비밀정보가 포함되어 있을 수 있으며, 지정된 수신자에 한하여 조회 및 사용될 수 있습니다. 만약 송신자의 실수로 인하여 상기 메시지를 수신하였다면, 송신자에게 메시지를 반송해 주시고, 원본 메시지와 모든 사본을 폐기해 주시기 바랍니다. 상기 메시지의 전체 또는 일부에 대해 무단 열람, 사용, 공개, 배포하는 것은 금지되어 있습니다.(주)LG CNS. This message and its attachments may contain confidential information, and they are intended to be viewed or used by only the individuals specified in the message. If you have received this message in an error from the sender, please contact the sender immediately to notify the error and delete all of the message and its copies. It is prohibited to view, use, make public and/or distribute part or whole of this message without written permission.

2 3

[Maria-developers] I wonder what elements add to CMakeLists.txt
by kyung nam Kim 23 Mar '15

23 Mar '15

Dears. I'm a newer in maria develper community. I'm develping a simple plugin for monitoring. If I access from other module to my plugin interface, I wonder how and what elements add to CMakeLists.txt. for example, My plugin is daemon type and myplugin.h has a definition of public methodA. I want to use methodA in my plugin from sql/sql_parse.cc . I think that information of library is needed at build time. ( -L, -l option) I don't know how to add that elements to CMakeLists.txt. plz,let me know. Thanks in advance.

2 5

Re: [Maria-developers] [server] Execute sync_with_master before SELECT in rpl_gtid_basic.test (#31)
by Kristian Nielsen 23 Mar '15

23 Mar '15

f4rnham <notifications(a)github.com> writes: > Usually slave synchronized on its own before select, but not always. Those two lines were probably swapped by accident > You can view, comment on, or merge this pull request online at: Indeed, silly mistake... This was already fixed in 10.0, so it will be merged to 10.1 that way. But thanks for looking into this anyway, it's good to be aware of these kinds of races in replication tests, they are quite common. - Kristian.

1 0

Re: [Maria-developers] [JIRA] (MDEV-7557) Option to put into slow log any transaction that was retried in parallel replication
by Kristian Nielsen 23 Mar '15

23 Mar '15

"Sergei Golubchik (JIRA)" <jira(a)mariadb.atlassian.net> writes: >> Key: MDEV-7557 >> URL: https://mariadb.atlassian.net/browse/MDEV-7557 >> In optimistic parallel replication (MDEV-6676), we speculatively apply >> transactions in parallel, even if they might conflict. If too many conflicts >> happen, excessive retry might degrade performance. >> The DBA needs some way to monitor for such problems. One good way would seem >> to have an option to add to the slow query log any transactions that were >> retried due to parallel replication conflicts. Possibly with extra information >> such as duration of transaction and similar. > I'm not sure that slow log is a good match for this kind of events Right. So do you have a suggestion for a better way? I was thinking on --log-queries-not-using-indexes, which similarly uses the slow query log to expose certain kinds of problematic queries. So queries that cause deadlocks could be another useful filter for the slow log (it should then probably be for all queries that deadlock, not just replication queries). In non-parallel replication, we put deadlock errors as warnings in the error log. But I disabled that for parallel replication. In non-parallel replication, you normally do not expect any deadlocks (since there is only one thread, how can it deadlock?). But in parallel replication, deadlocks are generally unavoidable, and not harmful. And DBAs do not like noise in the error logs that does not indicate a problem and cannot be removed. One option might be to log deadlocks as INFO level in the error log, and then users can temporarily raise verbosity level to see them? Another option could be to add an option to enable/disable logging deadlocks as warnings in parallel replication. (Though probably you will think as me, that this feels a bit like too ad-hoc an option to add.) Any other ideas? - Kristian.

2 1

[Maria-developers] GSoC 2015: Indexes on Virtual Columns and Array Based UDFs
by Richa Sehgal 20 Mar '15

20 Mar '15

Dear mentors, I am currently pursuing Master's in University of Illinois at Urbana Champaign, USA and completed by B.Tech from Indian Institute of Technology - Delhi (IIT- Delhi) This is regarding GSoC 2015. I am really interested in databases, and I was very excited to see all these projects listed here. The exciting part was that some of the projects are really “hard” as in they have challenged the database community since a long time, and thus it would be very interesting to solve some of these challenges as part of GSoC. I want to discuss 2 projects: A. Indexes on virtual columns Materialization gives us two things: 1. A name to the column which we can use in queries 2. A formal "regular" column which is stored and indexed in the regular fashion - Disadvantage: Extra memory requirements for the materialized column. My initial thoughts on this project are the following: We do need the name of the column which can be used to query. So maybe we can expose a command such as: create virtual_index <name> on <column_name> <expression> What this would do would run a regular query which evaluates expressions (like in WHERE clause) and the feed the result into the indexer. This index can then be stored in the regular fashion. B. Having UDFs returning an array/set There are three approaches that I can think of: 1. Supporting array/set as native datatype inside MariaDB (like int64, double, etc) - This might be hard and touches all levels of stack. 2. Have the array/set pass in serialized form to the above node of query execution and have appropriate deserializer when we want to interpret the result - Coming up with ser/deser strategy might be tough and this would be expensive too. 3. The query execution would be in a Tree structure where each node must be exposing functions like init(), next(), read(int col_index), etc. Maybe we can use this to emulate the evaluation of UDF against row. I think this is the suggestion that is listed in the project. I would like to get some direction on this from the mentors. I would like to discuss these and then decide on one of them. Am I approaching this in the right direction? Can you please point me to the next steps? Thanks Richa

3 9

[Maria-developers] Tasks for newcomer
by Martin Kaluznik 19 Mar '15

19 Mar '15

Hello, I am student interested in GSoC project Automatic provisioning of slave ( https://mariadb.atlassian.net/browse/MDEV-7502 ). Who would like to contribute to codebase. I will appreciate if somebody could suggest me something to work on. I found something really small for myself (https://mariadb.atlassian.net/browse/MDEV-7780 ) and implemented it in most basic way. https://github.com/f4rnham/server/commits/MDEV-7780 Config entry for case specified in report would be fake_version=5.5.25 It will probably require test case too, and I am not sure if this feature will be actually safe, it may create some inconsistencies. I have never worked with bzr before, but if it will be required, I will look into that. Thanks for feedback, Martin Kaluznik ( martin.kaluznik(a)gmail.com ). I can be also found on IRC under nick Farnham

2 1

Re: [Maria-developers] 1cda762: MDEV-6069: Remove old logic for 3.23-to-higher upgrades from upgrade SQL scripts
by Sergei Golubchik 19 Mar '15

19 Mar '15

Hi, Nirbhay! On Mar 17, Nirbhay Choubey wrote: > revision-id: 1cda762d3f1132e6696e1c451435746db0a1420a > parent(s): b0542b78c866fb32383f759914b10f060d0e14cd > committer: Nirbhay Choubey > branch nick: server > timestamp: 2015-03-17 11:20:49 -0400 > message: > > MDEV-6069: Remove old logic for 3.23-to-higher upgrades from upgrade SQL scripts > > Fix for failing tests. > > * Update mysql_system_tables_fix.sql to makeup the differences in system > tables in 5.1.17 (main.system_mysql_db_fix50117) I don't quite understand that. Why these ALTER TABLEs were not needed before? > * Removed system_mysql_db tests for versions 5.0.30 & 4.1.23. ok Regards, Sergei

3 3

[Maria-developers] [GSoC] MDEV-7502 Automatic provisioning of slave
by Martin Kaluznik 18 Mar '15

18 Mar '15

Hello, I am student interested in GSoC project Automatic provisioning of slave ( https://mariadb.atlassian.net/browse/MDEV-7502 ). I have read current code and put together my idea of how it could be implemented. Please correct me if there is better solution for some steps or I just misunderstood something. Slave starts regular sql thread and something really similar to current io thread (maybe best to begin with will be copy of handle_slave_io and related functions, it may still end with some duplicate code, which at the end can be moved to new common functions). Slave will receive gtids of current master as response to copy-modified version of COM_BINLOG_DUMP, they will mark position from which binlogs will be sent to slave. Master proceeds with building of list containing what needs to be sent to slave. Here exact implementation will depend on whether the master itself will block any DDL queries during provisioning process or not. If he will (probably won’t – it’s not necessary and it will just slow him down), we will have guaranteed that internal containers with databases/tables won’t change and they can be just iterated through safely (not true for procedure/trigger containers?). In other case, it will be probably required to prefetch list of databases/tables to copy to slave (it can be done lazily with tables/triggers/procedures/…, holding only list of tables/… for database which is currently being processed). In the second case, slave will have to detect DDL event and interrupt connection. The range scans on primary key mentioned in description, I assume it would look like SELECT * FROM tbl WHERE pk > @lastChunkKey ORDER BY pk LIMIT @chunkSize; just done with internal functions more efficiently, and the result will be converted to Rows_log_event which will be sent to slave. To restrictions I would add at least one more, provisioning cannot be continued if master is restarted during process (or can we actually store information about provisioning process in database?). Another possible problem could be slave reconnect. I found kill_zombie_dump_threads function, in this case, new thread could take information about provisioning progress from old thread and with help of fake gtids bundled with chunks somehow figure out which chunk was last successfully received by slave before disconnect. It would require additional memory to store few (or more?) most recently sent chunks and wouldn't guarantee success. Great way to solve this would be, to be able to map gtid sequence number to exact chunk of data, but I can’t see how it can be done without assuming something about maximum amount of rows in table / number of tables / triggers / … Thanks for feedback, Martin Kaluznik ( martin.kaluznik [at] gmail.com ). I can be also found on IRC under nick Farnham

2 1

Re: [Maria-developers] [Commits] 2bdbfd3: Fix assertion failure seen on Buildbot win32-debug
by Sergei Golubchik 18 Mar '15

18 Mar '15

Hi, Jan! On Mar 18, Jan Lindström wrote: > revision-id: 2bdbfd334bba93f75b2952e8e76f20ed29fb2bd4 > parent(s): c14d9c21f0a6974d9909e00a23522114caad3bfc > committer: Jan Lindström > branch nick: 10.0-git > timestamp: 2015-03-18 12:18:39 +0200 > message: > > Fix assertion failure seen on Buildbot win32-debug > > There is a bug in Visual Studio 2010 > Visual Studio has a feature "Checked Iterators". In a debug build, every > iterator operation is checked at runtime for errors, e g, out of range. > Disable this "Checked Iterators" for Windows and Debug if defined. This comment, > +/* There is a bug in Visual Studio 2010 > +Visual Studio has a feature "Checked Iterators". In a debug build, every > +iterator operation is checked at runtime for errors, e g, out of range. > +Disable this "Checked Iterators" for Windows and Debug if defined. > +*/ and this comment don't explain what bug is it. They create an impression that Visual Studio has run-time checks for an iterator running out of range. And that our code fails this check (because the iterator runs out of range). And that your "fix" is to disable the check instead of fixing the buggy out-of-range iterator. I'm not saying that's what happens, I'm saying that your comment suggests that this happens, because you didn't describe what was the actual bug. A better comment should say that our iterator is correct, but a buggy check erroneously marks it as out-of-range. It should explain what iterator is it, exactly, why it's correct, etc. Could you please fix the comment please? (or the iterator, whatever should be fixed) > +#ifdef UNIV_DEBUG > +#ifdef __WIN__ > +#ifdef _ITERATOR_DEBUG_LEVEL > +#define _ITERATOR_DEBUG_LEVEL 0 this will produce a warning "macro _ITERATOR_DEBUG_LEVEL is redefined" > +#endif /* _ITERATOR_DEBUG_LEVEL */ > +#endif /* __WIN__*/ > +#endif /* UNIV_DEBUG */ Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 97037da: Replace static usage of AES_CTR with current encryption algorithm.
by Jeremy Cole 18 Mar '15

18 Mar '15

Howdy Jan, > But the whole encryption_algorithm stuff seems not well thought out in any >> case. >> > > This was introduced because we can't assume that all installations will > install openSSL especially on Windows, thus encryption should work > with bundled yaSSL also. Do you have some better suggestion ? > Yes, I assumed so, but the current implementation is lazy and user-hostile. And, to me, having a single global variable controlling "the" encryption algorithm (for what, exactly?) is weird. Presumably if it makes sense to have it changeable, it also makes sense to set different algorithms for different objects. At a minimum, IMHO: store the encryption_algorithm selection with each encrypted object so that data can be migrated in the future. Then, implement sufficient support in the various necessary places so that it can be safely changed. Currently as far as I can tell it is globally set once, and impossible to change in the future. This could be done via stealing some bits from either the stored encryption scheme (1 byte) or key version (4 bytes) or adding a new encryption algorithm field which is stored alongside those everywhere (this is probably the best strategy IMHO, but takes a bit of thought). Alternatively as an absolute (and even lower) minimum: ensure that changing it once the database is initialized produces a loud and very clear error message to the user. Regards, Jeremy

1 0

[Maria-developers] Fwd: Port InnoDB memcached interface to MariaDB (GSOC 2015)
by Aalekh Nigam 18 Mar '15

18 Mar '15

Hello, I am Aalekh Nigam, 3rd Year Undergraduate student at JIIT Noida, India. I would like to propose my participation for Port InnoDB Memcache Interface to MariaDB (https://mariadb.atlassian.net/browse/MDEV-4674) as GSOC 2015 Student. Although I have been continuously involved with discussion regarding the project with the assigned mentor (Colin Charles), but would also like to propose my raw architecture for community participation , thus I would like to *request* you all to please go through the given architecture and follow up with your comments and remarks.Since the feature is critical to MariaDB, thus I will work hard on your comments and remarks to make this project a success. Architecture: According to my understanding this is the working that should be done for the project : Following are the main advantages which will come after integrating memcache to XtraDB (MariaDB Engine): - This memcache interfacing with MaraDB would help in faster execution of query in MaraDB Server. - Data can be unstructured or structured, depending on the type of application. You can make an all-new table for the data, or map the NoSQL-style processing to one or more existing tables. - Data that is requested through the memcached protocol is transparently queried from an XtraDB table, without going through the MariaDB SQL layer. - Because memcached consumes relatively little CPU, and its memory footprint is easy to control, it can run comfortably alongside a MariaDB instance on the same system. - Because memcached consumes relatively little CPU, and its memory footprint will be easy to control, it would run comfortably alongside a MariaDB instance on the same system. Detail Architecture: - Will have multi column key value support. - Will control memcache parameters through parameters like: read/write batch size, commit interval. - Direct access to XtraDb tables, bypassing the MariaDB SQL parser, the optimizer, and even the Handler API layer Thank You *Aalekh*

1 0

Re: [Maria-developers] [Commits] 97037da: Replace static usage of AES_CTR with current encryption algorithm.
by Jeremy Cole 17 Mar '15

17 Mar '15

> > I don't get it. Why is example_key_management_plugin special here? If >> you're going to support "none", why not here as well? >> > > This is exactly similar to file_key_management_plugin i.e. do not > initialize if NONE. > Heh, okay. > + >>> + my_aes_init_dynamic_encrypt(current_aes_dynamic_method); >>> >> >> Isn't this redundant? It should already be initialized by the call in >> init_server_components... >> >> >> > Maybe, but what if you load this plugin after server has started ? > Why would it matter? Unless I miss something, my_aes_encrypt_dynamic/my_aes_decrypt_dynamic are global. But the whole encryption_algorithm stuff seems not well thought out in any case. Regards, Jeremy

2 1

Re: [Maria-developers] [Commits] 97037da: Replace static usage of AES_CTR with current encryption algorithm.
by Jeremy Cole 17 Mar '15

17 Mar '15

Jan, > - my_aes_init_dynamic_encrypt(MY_AES_ALGORITHM_CTR); > + if (current_aes_dynamic_method == MY_AES_ALGORITHM_NONE) > + { > + sql_print_error("No encryption method choosen with > --encryption-algorithm. " > + "example_key_management_plugin disabled"); > + return 1; > + } > I don't get it. Why is example_key_management_plugin special here? If you're going to support "none", why not here as well? > + > + my_aes_init_dynamic_encrypt(current_aes_dynamic_method); > Isn't this redundant? It should already be initialized by the call in init_server_components... Regards, Jeremy

1 0

[Maria-developers] MDEV-6714: A couple of questions
by Vicențiu Ciorbaru 16 Mar '15

16 Mar '15

Hi Sergei, I've achieved the desired performance speedup related to MDEV-6714. You can check the preliminary patch on the commits mailing-list. I'll clean up the code and then submit a final version for review. I do however have two concerns: * By using SHOW TABLES LIKE %s, we performed a case insensitive search to find the table's correct name case. This command takes a long time with a lot of tables. Using an equality operator in I_D speeds it up, but it no longer matches if we have a different case. Possible solution: Try to search for the table with the provided string via INFORMATION_SCHEMA using the equals operator. If we can not find the table, fall back to a case insensitive search that takes longer. * The I_S.triggers and I_S.tables are available since 5.5 and 5.1 respectively. I suppose it is safe to assume we will have these tables available when running mysqldump. I can code all the changes to fall back to the previous query if the one that uses I_S tables fails. Regards, Vicentiu

3 3

Re: [Maria-developers] 53b73a7: MDEV-6714 mysqldump slow with tables in big databases
by Sergei Golubchik 16 Mar '15

16 Mar '15

Hi, Vicentiu! On Mar 16, vicentiu(a)mariadb.org wrote: > revision-id: 53b73a7940039809a02184a69502142d767b0741 > parent(s): 197afb413fcc9f06b5e5e6ef41ce980d108b354f > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-03-16 21:59:26 +0200 > message: > > MDEV-6714 mysqldump slow with tables in big databases > > First draft commit. Performance speedup achieved. > > --- > client/mysqldump.c | 15 ++++++++++----- > 1 file changed, 10 insertions(+), 5 deletions(-) > > diff --git a/client/mysqldump.c b/client/mysqldump.c > index 2da4ce6..6138e94 100644 > --- a/client/mysqldump.c > +++ b/client/mysqldump.c > @@ -3341,7 +3341,8 @@ static int dump_triggers_for_table(char *table_name, char *db_name) > /* Get list of triggers. */ > > my_snprintf(query_buff, sizeof(query_buff), > - "SHOW TRIGGERS LIKE %s", > + "SELECT TRIGGER_NAME from INFORMATION_SCHEMA.TRIGGERS " > + "where TRIGGER_SCHEMA = DATABASE() and EVENT_OBJECT_TABLE = %s", This is wrong, should be EVENT_OBJECT_SCHEMA, not TRIGGER_SCHEMA. Why? That's how I_S optimizations work - for file-based objects it might either use readdir to get all files and then select those that it needs. Or it can open the requested file directly, if it knows the database (= directory name) and the object name (= file name). It kind of works like an index over (db_name, object_name). And what fields are "indexed" is specified in the ST_SCHEMA_TABLE structure for the I_S table in question. For I_S.TRIGGERS it's {"TRIGGERS", triggers_fields_info, 0, get_all_tables, make_old_format, get_schema_triggers_record, 5, 6, 0, OPEN_TRIGGER_ONLY|OPTIMIZE_I_S_TABLE}, where triggers_fields_info is the list of fields and 5,6 are "indexed" fields. Looking at triggers_fields_info you'll see that 5,6 fields are EVENT_OBJECT_SCHEMA and EVENT_OBJECT_TABLE. > quote_for_like(table_name, name_buff)); > > if (mysql_query_with_error_report(mysql, &show_triggers_rs, query_buff)) > @@ -4716,8 +4717,12 @@ static char *get_actual_table_name(const char *old_table_name, MEM_ROOT *root) > > /* Check memory for quote_for_like() */ > DBUG_ASSERT(2*sizeof(old_table_name) < sizeof(show_name_buff)); > - my_snprintf(query, sizeof(query), "SHOW TABLES LIKE %s", > + my_snprintf(query, sizeof(query), > + "select table_name from information_schema.tables " > + "where table_schema = DATABASE() " > + "and table_name = %s", > quote_for_like(old_table_name, show_name_buff)); This is wrong, here and everywhere. quote_for_like() quotes, exactly, for LIKE. It is a wrong kind of quoting for equality operator. > + verbose_msg(query); > Regards, Sergei

1 0

Re: [Maria-developers] Gsoc 2015 - Enhancing mysqlbinlog
by Kristian Nielsen 16 Mar '15

16 Mar '15

Christos Daskalakis <daskalakis.chris(a)gmail.com> writes: > i found this very interesting project on gsoc 2015 and with another > colleague (Stelios Agapiou steagap06(a)gmail.com) we would be very > interested and happy to work on Enhancing mysqlbinlog , as it is referred > to in mariadb.com . I assume you are refering to MDEV-4989: https://mariadb.atlassian.net/browse/MDEV-4989 Rohit Kashyap also showed some interest in this project, and it was discussed a bit on the maria-developers@ mailing list (Cc:ed). So let's coordinate the efforts here. I updated the MDEV-4989 with what was discussed so far, it now better reflects what the project entails. It also now has some pointers to suggested background reading. Thank you for your interest in MariaDB, and MariaDB GTID! - Kristian.

2 1

Re: [Maria-developers] 7c21ea9: MDEV-7772: SIGSEGV on my_aes_encrypt_cbc when -DWITH_SSL=bundled
by Sergei Golubchik 14 Mar '15

14 Mar '15

Hi, Jan! On Mar 14, Jan Lindström wrote: > > and thanks for the review, some comments/questions below: > > > 1. Does file_key_management_plugin work with CTR? > > > Yes it does, but only with openSSL. Then I'd suggest to * add aes_ctr combination to have_file_key_management_plugin.combinations * use only one combinations file, not two identical ones (it can be called, say, encryption_algorithms.inc) and included into both have_*_key_management_plugin.inc files * disable aes_ctr combination from suite.pm, now it has $skip{'include/have_openssl_ctr.inc'} = 'no or too old openssl' unless $::mysqld_variables{'version-ssl-library'} =~ /OpenSSL (\S+)/ and $1 ge "1.0.1"; which disables the complete have_openssl_ctr.inc, it can be changed to disable just one combination (like for have_innodb.inc): $skip{'include/encryption_algorithms.combinations'} = [ 'aes_ctr' ] unless $::mysqld_variables{'version-ssl-library'} =~ /OpenSSL (\S+)/ and $1 ge "1.0.1"; > > This doesn't make a lot of sense now, because > > example_key_management_plugin forces CTR: > > > > my_aes_init_dynamic_encrypt(MY_AES_ALGORITHM_CTR); > > > Is there some reason why it does this here? I will change that on separate > fix to current_aes_dynamic_method if != MY_AES_ALGORITHM_NONE I suspect it was in the original google patch and nobody fixed it yet. It would be good to change it. Regards, Sergei

1 0

Re: [Maria-developers] 7ef6793: MDEV-6650 - LINT_INIT emits code in non-debug builds
by Sergei Golubchik 13 Mar '15

13 Mar '15

Hi, Sergey! On Feb 10, svoj(a)mariadb.org wrote: > revision-id: 7ef679355dfe07eba88964e78a3303e6eddd618c > parent(s): f13939061d468a47985dee0268652a6fe2db7862 > committer: Sergey Vojtovich > branch nick: 10.1 > timestamp: 2015-02-10 14:05:49 +0400 > message: > > MDEV-6650 - LINT_INIT emits code in non-debug builds > > Replaced all references to LINT_INIT with UNINIT_VAR and LINT_INIT_STRUCT. > Removed LINT_INIT macro. Ok to push Regards, Sergei

1 0

Re: [Maria-developers] 7c21ea9: MDEV-7772: SIGSEGV on my_aes_encrypt_cbc when -DWITH_SSL=bundled
by Sergei Golubchik 13 Mar '15

13 Mar '15

Hi, Jan! On Mar 13, Jan Lindström wrote: > revision-id: 7c21ea9f502ded155c12a0ee3c5ff0602e9d4c9a > parent(s): 4d0e52189ca945c94146035c2733d85c9c6fd18d > committer: Jan Lindström > branch nick: 10.1-innodb > timestamp: 2015-03-13 14:18:07 +0200 > message: > > MDEV-7772: SIGSEGV on my_aes_encrypt_cbc when -DWITH_SSL=bundled > > Two problems: > - Read/Write outside of buffer at memcpy() because of incorrect parameters > . OPENSSL_assert(EVP_CIPHER_CTX_iv_length(&ctx.ctx) == iv_length); // ECB does not use IV, thus incorrect assertion > > Added: > mysql-test/include/have_file_key_management_plugin.combinations ( to run with aes_cbc and aes_ecb) > mysql-test/include/have_openssl_ctr.combinations ( to run with aes_cbc, aes_ecb and aes_ctr) The patch is ok, of course. Just a few suggestions, see below. Ok to push after that. > diff --git a/mysql-test/include/have_file_key_management_plugin.combinations b/mysql-test/include/have_file_key_management_plugin.combinations > new file mode 100644 > index 0000000..6a63b5a > --- /dev/null > +++ b/mysql-test/include/have_file_key_management_plugin.combinations > @@ -0,0 +1,6 @@ > +[aes_cbc] > +encryption-algorithm=aes_cbc > + > +[aes_ecb] > +encryption-algorithm=aes_ecb > + 1. Does file_key_management_plugin work with CTR? 2. suggestion: use shorter names for combinations (I'd remove "aes_" prefix) test names are long enough already. See replication combinations - they are 3-4 letters only (rbr/mix/stmt). > diff --git a/mysql-test/include/have_openssl_ctr.combinations b/mysql-test/include/have_openssl_ctr.combinations > new file mode 100644 > index 0000000..2c49c78 > --- /dev/null > +++ b/mysql-test/include/have_openssl_ctr.combinations > @@ -0,0 +1,9 @@ > +[aes_cbc] > +encryption-algorithm=aes_cbc > + > +[aes_ecb] > +encryption-algorithm=aes_ecb > + > +[aes_ctr] > +encryption-algorithm=aes_ctr > + This doesn't make a lot of sense now, because example_key_management_plugin forces CTR: my_aes_init_dynamic_encrypt(MY_AES_ALGORITHM_CTR); so it always uses ctr, no matter what encryption-algorithm is. which is very confusing, SHOW VARIABLES will show, say, aes_ecb, but in fact it will be aes_ctr under the hood. furthermore, it doesn't check for the return value (so it'll fail later or will misbehave on old openssl versions that don't support CTR). This all is a separate bug (in Jira already), but for now I'm just saying that it's kind of pointless to run example_key_management_plugin with different encryption-algorithm values. > diff --git a/mysql-test/suite/innodb/t/innodb_scrub_background.test b/mysql-test/suite/innodb/t/innodb_scrub_background.test > index 44cb16b..881c124 100644 > --- a/mysql-test/suite/innodb/t/innodb_scrub_background.test > +++ b/mysql-test/suite/innodb/t/innodb_scrub_background.test > @@ -1,6 +1,7 @@ > -- source include/have_innodb.inc > -- source include/not_embedded.inc > -- source include/have_example_key_management_plugin.inc > +-- source include/have_openssl_ctr.inc that's fine, although you could've simply included have_openssl_ctr.inc from have_example_key_management_plugin.inc :) > > let $MYSQLD_DATADIR=`select @@datadir`; > let ib1_IBD = $MYSQLD_DATADIR/ibdata1; > diff --git a/storage/innobase/fil/fil0crypt.cc b/storage/innobase/fil/fil0crypt.cc > index 823c74a..10d49bb 100644 > --- a/storage/innobase/fil/fil0crypt.cc > +++ b/storage/innobase/fil/fil0crypt.cc > @@ -734,7 +734,7 @@ fil_space_encrypt(ulint space, ulint offset, lsn_t lsn, > uint32 dstlen; > > if (page_compressed) { > - srclen = page_size - FIL_PAGE_DATA;; > + srclen = page_size - FIL_PAGE_DATA; I'd suggest to move this and all following changes to a separate commit. > } > > int rc = (* my_aes_encrypt_dynamic)(src, srclen, Regards, Sergei

1 0

Re: [Maria-developers] 20e5c37: MDEV-7728 - Spiral patch 032_mariadb-10.0.15.scale_registering_xid.diff
by Sergei Golubchik 13 Mar '15

13 Mar '15

Hi, Sergey! On Mar 12, svoj(a)mariadb.org wrote: > revision-id: 20e5c37ccfac9d95a2db1f295f211656df1ce160 > parent(s): 190858d996e7dc90e01fe8a5e7daec6af0012b23 > committer: Sergey Vojtovich > branch nick: 10.1 > timestamp: 2015-03-12 18:15:08 +0400 > message: > > MDEV-7728 - Spiral patch 032_mariadb-10.0.15.scale_registering_xid.diff > > XID cache is now based on lock-free hash. > Also fixed lf_hash_destroy() to call alloc destructor. > > Note that previous implementation had race condition when thread was accessing > XA owned by different thread. This new implementation doesn't fix it either. > > diff --git a/include/lf.h b/include/lf.h > index 88024bc..19bdafc 100644 > --- a/include/lf.h > +++ b/include/lf.h > @@ -117,7 +117,12 @@ void lf_pinbox_init(LF_PINBOX *pinbox, uint free_ptr_offset, > #define lf_alloc_free(PINS, PTR) lf_pinbox_free((PINS), (PTR)) > #define lf_alloc_get_pins(A) lf_pinbox_get_pins(&(A)->pinbox) > #define lf_alloc_put_pins(PINS) lf_pinbox_put_pins(PINS) > -#define lf_alloc_direct_free(ALLOC, ADDR) my_free((ADDR)) > +#define lf_alloc_direct_free(ALLOC, ADDR) \ > + do { \ > + if ((ALLOC)->destructor) \ > + (ALLOC)->destructor((uchar*) ADDR); \ > + my_free(ADDR); \ > + } while(0) > > void *lf_alloc_new(LF_PINS *pins); > > diff --git a/mysql-test/suite/innodb/r/innodb_bug59641.result b/mysql-test/suite/innodb/r/innodb_bug59641.result > index 5062c69..476385f 100644 > --- a/mysql-test/suite/innodb/r/innodb_bug59641.result > +++ b/mysql-test/suite/innodb/r/innodb_bug59641.result > @@ -43,8 +43,8 @@ COMMIT; > XA RECOVER; > formatID gtrid_length bqual_length data > 1 3 0 789 > -1 3 0 456 > 1 3 0 123 > +1 3 0 456 > XA ROLLBACK '123'; > XA ROLLBACK '456'; > XA COMMIT '789'; > diff --git a/mysql-test/suite/perfschema/r/server_init.result b/mysql-test/suite/perfschema/r/server_init.result > index 20dc130..1bdb988 100644 > --- a/mysql-test/suite/perfschema/r/server_init.result > +++ b/mysql-test/suite/perfschema/r/server_init.result > @@ -120,10 +120,6 @@ where name like "wait/synch/mutex/sql/LOCK_audit_mask"; > count(name) > 1 > select count(name) from mutex_instances > -where name like "wait/synch/mutex/sql/LOCK_xid_cache"; > -count(name) > -1 > -select count(name) from mutex_instances > where name like "wait/synch/mutex/sql/LOCK_plugin"; > count(name) > 1 > diff --git a/mysql-test/suite/perfschema/r/setup_instruments_defaults.result b/mysql-test/suite/perfschema/r/setup_instruments_defaults.result > index e502376..b0570d7 100644 > --- a/mysql-test/suite/perfschema/r/setup_instruments_defaults.result > +++ b/mysql-test/suite/perfschema/r/setup_instruments_defaults.result > @@ -5,14 +5,14 @@ SELECT * FROM performance_schema.setup_instruments > WHERE name IN ( > 'wait/synch/mutex/sql/LOCK_user_conn', > 'wait/synch/mutex/sql/LOCK_uuid_generator', > -'wait/synch/mutex/sql/LOCK_xid_cache', > +'wait/synch/mutex/sql/LOCK_plugin', > 'stage/sql/creating table') > AND enabled = 'yes' AND timed = 'no' > ORDER BY name; > NAME ENABLED TIMED > stage/sql/creating table YES NO > +wait/synch/mutex/sql/LOCK_plugin YES NO > wait/synch/mutex/sql/LOCK_user_conn YES NO > -wait/synch/mutex/sql/LOCK_xid_cache YES NO > SELECT * FROM performance_schema.setup_instruments > WHERE name = 'wait/synch/mutex/sql/LOCK_thread_count' > AND enabled = 'no' AND timed = 'no'; > diff --git a/mysql-test/suite/perfschema/t/server_init.test b/mysql-test/suite/perfschema/t/server_init.test > index d5a7e18..c6d25f1 100644 > --- a/mysql-test/suite/perfschema/t/server_init.test > +++ b/mysql-test/suite/perfschema/t/server_init.test > @@ -118,9 +118,6 @@ select count(name) from mutex_instances > where name like "wait/synch/mutex/sql/LOCK_audit_mask"; > > select count(name) from mutex_instances > - where name like "wait/synch/mutex/sql/LOCK_xid_cache"; > - > -select count(name) from mutex_instances > where name like "wait/synch/mutex/sql/LOCK_plugin"; > > # Not a global variable, may be destroyed already. > diff --git a/mysql-test/suite/perfschema/t/setup_instruments_defaults-master.opt b/mysql-test/suite/perfschema/t/setup_instruments_defaults-master.opt > index 408eb5c..ed6702e 100644 > --- a/mysql-test/suite/perfschema/t/setup_instruments_defaults-master.opt > +++ b/mysql-test/suite/perfschema/t/setup_instruments_defaults-master.opt > @@ -12,7 +12,7 @@ > --loose-performance-schema-instrument='wait/synch/mutex/sql/LOCK_thread_count=OFF' > --loose-performance-schema-instrument=' wait/synch/mutex/sql/LOCK_user_conn = COUNTED' > --loose-performance-schema-instrument='wait%/synch/mutex/sql/LOCK_uu%_genera%/= COUNTED' > ---loose-performance-schema-instrument='%%wait/synch/mutex/sql/LOCK_xid_cache=COUNTED' > +--loose-performance-schema-instrument='%%wait/synch/mutex/sql/LOCK_plugin=COUNTED' > --loose-performance-schema-instrument='%=FOO' > --loose-performance-schema-instrument='%=%' > --loose-performance-schema-instrument='%' > diff --git a/mysql-test/suite/perfschema/t/setup_instruments_defaults.test b/mysql-test/suite/perfschema/t/setup_instruments_defaults.test > index e1f6140..5e0a3a5 100644 > --- a/mysql-test/suite/perfschema/t/setup_instruments_defaults.test > +++ b/mysql-test/suite/perfschema/t/setup_instruments_defaults.test > @@ -15,7 +15,7 @@ SELECT * FROM performance_schema.setup_instruments > WHERE name IN ( > 'wait/synch/mutex/sql/LOCK_user_conn', > 'wait/synch/mutex/sql/LOCK_uuid_generator', > - 'wait/synch/mutex/sql/LOCK_xid_cache', > + 'wait/synch/mutex/sql/LOCK_plugin', > 'stage/sql/creating table') > AND enabled = 'yes' AND timed = 'no' > ORDER BY name; > diff --git a/sql/handler.cc b/sql/handler.cc > index 12d7ffb..a45419f 100644 > --- a/sql/handler.cc > +++ b/sql/handler.cc > @@ -1931,12 +1931,28 @@ int ha_recover(HASH *commit_list) > so mysql_xa_recover does not filter XID's to ensure uniqueness. > It can be easily fixed later, if necessary. > */ > + > +static my_bool xa_recover_callback(XID_STATE *xs, Protocol *protocol) > +{ > + if (xs->xa_state == XA_PREPARED) > + { > + protocol->prepare_for_resend(); > + protocol->store_longlong((longlong) xs->xid.formatID, FALSE); > + protocol->store_longlong((longlong) xs->xid.gtrid_length, FALSE); > + protocol->store_longlong((longlong) xs->xid.bqual_length, FALSE); > + protocol->store(xs->xid.data, xs->xid.gtrid_length + xs->xid.bqual_length, > + &my_charset_bin); > + if (protocol->write()) > + return TRUE; > + } > + return FALSE; > +} > + > + > bool mysql_xa_recover(THD *thd) > { > List<Item> field_list; > Protocol *protocol= thd->protocol; > - int i=0; > - XID_STATE *xs; > DBUG_ENTER("mysql_xa_recover"); > > field_list.push_back(new Item_int("formatID", 0, MY_INT32_NUM_DECIMAL_DIGITS)); > @@ -1948,26 +1964,9 @@ bool mysql_xa_recover(THD *thd) > Protocol::SEND_NUM_ROWS | Protocol::SEND_EOF)) > DBUG_RETURN(1); > > - mysql_mutex_lock(&LOCK_xid_cache); > - while ((xs= (XID_STATE*) my_hash_element(&xid_cache, i++))) > - { > - if (xs->xa_state==XA_PREPARED) > - { > - protocol->prepare_for_resend(); > - protocol->store_longlong((longlong)xs->xid.formatID, FALSE); > - protocol->store_longlong((longlong)xs->xid.gtrid_length, FALSE); > - protocol->store_longlong((longlong)xs->xid.bqual_length, FALSE); > - protocol->store(xs->xid.data, xs->xid.gtrid_length+xs->xid.bqual_length, > - &my_charset_bin); > - if (protocol->write()) > - { > - mysql_mutex_unlock(&LOCK_xid_cache); > - DBUG_RETURN(1); > - } > - } > - } > - > - mysql_mutex_unlock(&LOCK_xid_cache); > + if (xid_cache_iterate(thd, (my_hash_walk_action) xa_recover_callback, > + protocol)) > + DBUG_RETURN(1); > my_eof(thd); > DBUG_RETURN(0); > } > diff --git a/sql/handler.h b/sql/handler.h > index 5ef9208..5ab67c0 100644 > --- a/sql/handler.h > +++ b/sql/handler.h > @@ -612,11 +612,11 @@ struct xid_t { > return sizeof(formatID)+sizeof(gtrid_length)+sizeof(bqual_length)+ > gtrid_length+bqual_length; > } > - uchar *key() > + uchar *key() const > { > return (uchar *)&gtrid_length; > } > - uint key_length() > + uint key_length() const > { > return sizeof(gtrid_length)+sizeof(bqual_length)+gtrid_length+bqual_length; > } > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index b97742d..6c06240 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -4889,11 +4889,7 @@ static int init_server_components() > my_charset_error_reporter= charset_error_reporter; > #endif > > - if (xid_cache_init()) > - { > - sql_print_error("Out of memory"); > - unireg_abort(1); > - } > + xid_cache_init(); > > /* > initialize delegates for extension observers, errors have already > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index 5b0d04d..d59ef52 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -914,7 +914,8 @@ bool Drop_table_error_handler::handle_condition(THD *thd, > wait_for_commit_ptr(0), > main_da(0, false, false), > m_stmt_da(&main_da), > - tdc_hash_pins(0) > + tdc_hash_pins(0), > + xid_hash_pins(0) > #ifdef WITH_WSREP > , > wsrep_applier(is_wsrep_applier), > @@ -1593,7 +1594,7 @@ void THD::cleanup(void) > > transaction.xid_state.xa_state= XA_NOTR; > trans_rollback(this); > - xid_cache_delete(&transaction.xid_state); > + xid_cache_delete(this, &transaction.xid_state); > > DBUG_ASSERT(open_tables == NULL); > /* > @@ -1704,6 +1705,8 @@ void THD::cleanup(void) > main_da.free_memory(); > if (tdc_hash_pins) > lf_hash_put_pins(tdc_hash_pins); > + if (xid_hash_pins) > + lf_hash_put_pins(xid_hash_pins); > /* Ensure everything is freed */ > if (status_var.local_memory_used != 0) > { > @@ -5106,120 +5109,205 @@ void mark_transaction_to_rollback(THD *thd, bool all) > /*************************************************************************** > Handling of XA id cacheing > ***************************************************************************/ > +class XID_cache_element > +{ > + uint m_state; shouldn't it be uint32 ? That's the type that my_atomic_add32/cas32 work with. > + static const uint DELETED= 1 << 31; > +public: > + XID_STATE *m_xid_state; O-okay. I *think* your hand-written locking logic works. But please add a comment, explaining how it works, all four methods, the meaning of DELETED, etc. Perhaps DELETED should rather be NOT_INITIALIZED? > + bool lock() > + { > + if (my_atomic_add32_explicit(&m_state, 1, MY_MEMORY_ORDER_ACQUIRE) & DELETED) > + { > + unlock(); > + return false; > + } > + return true; > + } > + void unlock() > + { > + my_atomic_add32_explicit(&m_state, -1, MY_MEMORY_ORDER_RELEASE); > + } > + void mark_deleted() > + { > + uint old= 0; > + while (!my_atomic_cas32_weak_explicit(&m_state, &old, DELETED, > + MY_MEMORY_ORDER_RELAXED, > + MY_MEMORY_ORDER_RELAXED)) usually one should use LF_BACKOFF inside spin-loops. > + old= 0; > + } > + void mark_not_deleted() > + { > + DBUG_ASSERT(m_state & DELETED); > + my_atomic_add32_explicit(&m_state, -DELETED, MY_MEMORY_ORDER_RELAXED); > + } > + static void lf_hash_initializer(LF_HASH *hash __attribute__((unused)), > + XID_cache_element *element, > + XID_STATE *xid_state) > + { > + element->m_xid_state= xid_state; > + xid_state->xid_cache_element= element; > + } > + static void lf_alloc_constructor(uchar *ptr) > + { > + XID_cache_element *element= (XID_cache_element*) (ptr + LF_HASH_OVERHEAD); > + element->m_state= DELETED; > + } > + static void lf_alloc_destructor(uchar *ptr) > + { > + XID_cache_element *element= (XID_cache_element*) (ptr + LF_HASH_OVERHEAD); > + if (element->m_state != DELETED) How can this happen? You mark an element DELETED before lf_hash_delete() > + { > + DBUG_ASSERT(!element->m_xid_state->in_thd); > + my_free(element->m_xid_state); > + } > + } > + static uchar *key(const XID_cache_element *element, size_t *length, > + my_bool not_used __attribute__((unused))) > + { > + *length= element->m_xid_state->xid.key_length(); > + return element->m_xid_state->xid.key(); > + } > +}; > > -mysql_mutex_t LOCK_xid_cache; > -HASH xid_cache; > > -extern "C" uchar *xid_get_hash_key(const uchar *, size_t *, my_bool); > -extern "C" void xid_free_hash(void *); > +static LF_HASH xid_cache; > +static bool xid_cache_inited; > > -uchar *xid_get_hash_key(const uchar *ptr, size_t *length, > - my_bool not_used __attribute__((unused))) > -{ > - *length=((XID_STATE*)ptr)->xid.key_length(); > - return ((XID_STATE*)ptr)->xid.key(); > -} > > -void xid_free_hash(void *ptr) > +bool THD::fix_xid_hash_pins() > { > - if (!((XID_STATE*)ptr)->in_thd) > - my_free(ptr); > + if (!xid_hash_pins) > + xid_hash_pins= lf_hash_get_pins(&xid_cache); > + return !xid_hash_pins; > } > > -#ifdef HAVE_PSI_INTERFACE > -static PSI_mutex_key key_LOCK_xid_cache; > > -static PSI_mutex_info all_xid_mutexes[]= > +void xid_cache_init() > { > - { &key_LOCK_xid_cache, "LOCK_xid_cache", PSI_FLAG_GLOBAL} > -}; > - > -static void init_xid_psi_keys(void) > -{ > - const char* category= "sql"; > - int count; > - > - if (PSI_server == NULL) > - return; > - > - count= array_elements(all_xid_mutexes); > - PSI_server->register_mutex(category, all_xid_mutexes, count); > + xid_cache_inited= true; > + lf_hash_init(&xid_cache, sizeof(XID_cache_element), LF_HASH_UNIQUE, 0, 0, > + (my_hash_get_key) XID_cache_element::key, &my_charset_bin); > + xid_cache.alloc.constructor= XID_cache_element::lf_alloc_constructor; > + xid_cache.alloc.destructor= XID_cache_element::lf_alloc_destructor; > + xid_cache.initializer= > + (lf_hash_initializer) XID_cache_element::lf_hash_initializer; > } > -#endif /* HAVE_PSI_INTERFACE */ > - > -bool xid_cache_init() > -{ > -#ifdef HAVE_PSI_INTERFACE > - init_xid_psi_keys(); > -#endif > > - mysql_mutex_init(key_LOCK_xid_cache, &LOCK_xid_cache, MY_MUTEX_INIT_FAST); > - return my_hash_init(&xid_cache, &my_charset_bin, 100, 0, 0, > - xid_get_hash_key, xid_free_hash, 0) != 0; > -} > > void xid_cache_free() > { > - if (my_hash_inited(&xid_cache)) > + if (xid_cache_inited) > { > - my_hash_free(&xid_cache); > - mysql_mutex_destroy(&LOCK_xid_cache); > + lf_hash_destroy(&xid_cache); > + xid_cache_inited= false; > } > } > > -XID_STATE *xid_cache_search(XID *xid) > + > +XID_STATE *xid_cache_search(THD *thd, XID *xid) > { > - mysql_mutex_lock(&LOCK_xid_cache); > - XID_STATE *res=(XID_STATE *)my_hash_search(&xid_cache, xid->key(), > - xid->key_length()); > - mysql_mutex_unlock(&LOCK_xid_cache); > - return res; > + DBUG_ASSERT(thd->xid_hash_pins); > + XID_cache_element *element= > + (XID_cache_element*) lf_hash_search(&xid_cache, thd->xid_hash_pins, > + xid->key(), xid->key_length()); > + if (element) > + { > + lf_hash_search_unpin(thd->xid_hash_pins); > + return element->m_xid_state; Normally, one should not access the element after it's unpinned, so the protocol is XID_STATE *state= element->m_xid_state; lf_hash_search_unpin(thd->xid_hash_pins); return state; Perhaps your locking/deleted m_state guarantees that element is safe to access? But I failed to see that :( > + } > + return 0; > } > > > bool xid_cache_insert(XID *xid, enum xa_states xa_state) > { > XID_STATE *xs; > - my_bool res; > - mysql_mutex_lock(&LOCK_xid_cache); > - if (my_hash_search(&xid_cache, xid->key(), xid->key_length())) > - res=0; > - else if (!(xs=(XID_STATE *)my_malloc(sizeof(*xs), MYF(MY_WME)))) > - res=1; > - else > + LF_PINS *pins; > + int res= 1; > + > + if (!(pins= lf_hash_get_pins(&xid_cache))) > + return true; > + > + if ((xs= (XID_STATE*) my_malloc(sizeof(*xs), MYF(MY_WME)))) > { > xs->xa_state=xa_state; > xs->xid.set(xid); > xs->in_thd=0; > xs->rm_error=0; > - res=my_hash_insert(&xid_cache, (uchar*)xs); > + > + if ((res= lf_hash_insert(&xid_cache, pins, xs))) > + my_free(xs); > + else > + xs->xid_cache_element->mark_not_deleted(); > + if (res == 1) > + res= 0; > } > - mysql_mutex_unlock(&LOCK_xid_cache); > + lf_hash_put_pins(pins); > return res; > } > > > -bool xid_cache_insert(XID_STATE *xid_state) > +bool xid_cache_insert(THD *thd, XID_STATE *xid_state) > { > - mysql_mutex_lock(&LOCK_xid_cache); > - if (my_hash_search(&xid_cache, xid_state->xid.key(), > - xid_state->xid.key_length())) > + if (thd->fix_xid_hash_pins()) > + return true; > + > + int res= lf_hash_insert(&xid_cache, thd->xid_hash_pins, xid_state); > + switch (res) > { > - mysql_mutex_unlock(&LOCK_xid_cache); > + case 0: > + xid_state->xid_cache_element->mark_not_deleted(); > + break; > + case 1: > my_error(ER_XAER_DUPID, MYF(0)); > - return true; > + default: > + xid_state->xid_cache_element= 0; > } > - bool res= my_hash_insert(&xid_cache, (uchar*)xid_state); > - mysql_mutex_unlock(&LOCK_xid_cache); > return res; > } > > > -void xid_cache_delete(XID_STATE *xid_state) > +void xid_cache_delete(THD *thd, XID_STATE *xid_state) > +{ > + if (xid_state->xid_cache_element) > + { > + DBUG_ASSERT(thd->xid_hash_pins); > + xid_state->xid_cache_element->mark_deleted(); > + lf_hash_delete(&xid_cache, thd->xid_hash_pins, > + xid_state->xid.key(), xid_state->xid.key_length()); > + xid_state->xid_cache_element= 0; > + if (!xid_state->in_thd) > + my_free(xid_state); > + } > +} > + > + > +struct xid_cache_iterate_arg > +{ > + my_hash_walk_action action; > + void *argument; > +}; > + > +static my_bool xid_cache_iterate_callback(XID_cache_element *element, > + xid_cache_iterate_arg *arg) > +{ > + my_bool res= FALSE; > + if (element->lock()) > + { > + res= arg->action(element->m_xid_state, arg->argument); > + element->unlock(); > + } > + return res; > +} > + > +int xid_cache_iterate(THD *thd, my_hash_walk_action action, void *arg) > { > - mysql_mutex_lock(&LOCK_xid_cache); > - my_hash_delete(&xid_cache, (uchar *)xid_state); > - mysql_mutex_unlock(&LOCK_xid_cache); > + xid_cache_iterate_arg argument= { action, arg }; > + return thd->fix_xid_hash_pins() ? -1 : > + lf_hash_iterate(&xid_cache, thd->xid_hash_pins, > + (my_hash_walk_action) xid_cache_iterate_callback, > + &argument); > } > > > diff --git a/sql/sql_class.h b/sql/sql_class.h > index bd145bd..200f541 100644 > --- a/sql/sql_class.h > +++ b/sql/sql_class.h > @@ -1105,6 +1105,7 @@ struct st_savepoint { > > enum xa_states {XA_NOTR=0, XA_ACTIVE, XA_IDLE, XA_PREPARED, XA_ROLLBACK_ONLY}; > extern const char *xa_state_names[]; > +class XID_cache_element; > > typedef struct st_xid_state { > /* For now, this is only used to catch duplicated external xids */ > @@ -1113,16 +1114,16 @@ struct st_savepoint { > bool in_thd; > /* Error reported by the Resource Manager (RM) to the Transaction Manager. */ > uint rm_error; > + XID_cache_element *xid_cache_element; > } XID_STATE; > > -extern mysql_mutex_t LOCK_xid_cache; > -extern HASH xid_cache; > -bool xid_cache_init(void); > +void xid_cache_init(void); > void xid_cache_free(void); > -XID_STATE *xid_cache_search(XID *xid); > +XID_STATE *xid_cache_search(THD *thd, XID *xid); > bool xid_cache_insert(XID *xid, enum xa_states xa_state); > -bool xid_cache_insert(XID_STATE *xid_state); > -void xid_cache_delete(XID_STATE *xid_state); > +bool xid_cache_insert(THD *thd, XID_STATE *xid_state); > +void xid_cache_delete(THD *thd, XID_STATE *xid_state); > +int xid_cache_iterate(THD *thd, my_hash_walk_action action, void *argument); > > /** > @class Security_context > @@ -3785,6 +3786,8 @@ class THD :public Statement, > } > > LF_PINS *tdc_hash_pins; > + LF_PINS *xid_hash_pins; > + bool fix_xid_hash_pins(); > > inline ulong wsrep_binlog_format() const > { > diff --git a/sql/transaction.cc b/sql/transaction.cc > index 22e3ad7..d6ef160 100644 > --- a/sql/transaction.cc > +++ b/sql/transaction.cc > @@ -738,7 +738,7 @@ bool trans_xa_start(THD *thd) > thd->transaction.xid_state.xa_state= XA_ACTIVE; > thd->transaction.xid_state.rm_error= 0; > thd->transaction.xid_state.xid.set(thd->lex->xid); > - if (xid_cache_insert(&thd->transaction.xid_state)) > + if (xid_cache_insert(thd, &thd->transaction.xid_state)) > { > thd->transaction.xid_state.xa_state= XA_NOTR; > thd->transaction.xid_state.xid.null(); > @@ -801,7 +801,7 @@ bool trans_xa_prepare(THD *thd) > my_error(ER_XAER_NOTA, MYF(0)); > else if (ha_prepare(thd)) > { > - xid_cache_delete(&thd->transaction.xid_state); > + xid_cache_delete(thd, &thd->transaction.xid_state); > thd->transaction.xid_state.xa_state= XA_NOTR; > my_error(ER_XA_RBROLLBACK, MYF(0)); > } > @@ -830,6 +830,11 @@ bool trans_xa_commit(THD *thd) > > if (!thd->transaction.xid_state.xid.eq(thd->lex->xid)) > { > + if (thd->fix_xid_hash_pins()) > + { > + my_error(ER_OUT_OF_RESOURCES, MYF(0)); > + DBUG_RETURN(TRUE); > + } > /* > xid_state.in_thd is always true beside of xa recovery procedure. > Note, that there is no race condition here between xid_cache_search > @@ -840,7 +845,7 @@ bool trans_xa_commit(THD *thd) > xa_cache_insert(XID, xa_states), which is called before starting > client connections, and thus is always single-threaded. > */ > - XID_STATE *xs= xid_cache_search(thd->lex->xid); > + XID_STATE *xs= xid_cache_search(thd, thd->lex->xid); > res= !xs || xs->in_thd; > if (res) > my_error(ER_XAER_NOTA, MYF(0)); > @@ -848,7 +853,7 @@ bool trans_xa_commit(THD *thd) > { > res= xa_trans_rolled_back(xs); > ha_commit_or_rollback_by_xid(thd->lex->xid, !res); > - xid_cache_delete(xs); > + xid_cache_delete(thd, xs); > } > DBUG_RETURN(res); > } > @@ -911,7 +916,7 @@ bool trans_xa_commit(THD *thd) > thd->server_status&= > ~(SERVER_STATUS_IN_TRANS | SERVER_STATUS_IN_TRANS_READONLY); > DBUG_PRINT("info", ("clearing SERVER_STATUS_IN_TRANS")); > - xid_cache_delete(&thd->transaction.xid_state); > + xid_cache_delete(thd, &thd->transaction.xid_state); > thd->transaction.xid_state.xa_state= XA_NOTR; > > DBUG_RETURN(res); > @@ -935,14 +940,20 @@ bool trans_xa_rollback(THD *thd) > > if (!thd->transaction.xid_state.xid.eq(thd->lex->xid)) > { > - XID_STATE *xs= xid_cache_search(thd->lex->xid); > + if (thd->fix_xid_hash_pins()) > + { > + my_error(ER_OUT_OF_RESOURCES, MYF(0)); > + DBUG_RETURN(TRUE); > + } > + > + XID_STATE *xs= xid_cache_search(thd, thd->lex->xid); > if (!xs || xs->in_thd) > my_error(ER_XAER_NOTA, MYF(0)); > else > { > xa_trans_rolled_back(xs); > ha_commit_or_rollback_by_xid(thd->lex->xid, 0); > - xid_cache_delete(xs); > + xid_cache_delete(thd, xs); > } > DBUG_RETURN(thd->get_stmt_da()->is_error()); > } > @@ -961,7 +972,7 @@ bool trans_xa_rollback(THD *thd) > thd->server_status&= > ~(SERVER_STATUS_IN_TRANS | SERVER_STATUS_IN_TRANS_READONLY); > DBUG_PRINT("info", ("clearing SERVER_STATUS_IN_TRANS")); > - xid_cache_delete(&thd->transaction.xid_state); > + xid_cache_delete(thd, &thd->transaction.xid_state); > thd->transaction.xid_state.xa_state= XA_NOTR; > > DBUG_RETURN(res); > diff --git a/storage/spider/spd_table.cc b/storage/spider/spd_table.cc > index 36768ae..411c7ae 100644 > --- a/storage/spider/spd_table.cc > +++ b/storage/spider/spd_table.cc > @@ -41,11 +41,13 @@ I'd prefer to have spider changes in a separate commit > #include "spd_malloc.h" > > ulong *spd_db_att_thread_id; > +#if MYSQL_VERSION_ID < 100103 > #ifdef XID_CACHE_IS_SPLITTED > uint *spd_db_att_xid_cache_split_num; > #endif > pthread_mutex_t *spd_db_att_LOCK_xid_cache; > HASH *spd_db_att_xid_cache; > +#endif > struct charset_info_st *spd_charset_utf8_bin; > const char **spd_defaults_extra_file; > const char **spd_defaults_file; > @@ -6263,7 +6265,7 @@ int spider_db_init( > "?LOCK_xid_cache@@3PAUst_mysql_mutex@@A")); > spd_db_att_xid_cache = *((HASH **) > GetProcAddress(current_module, "?xid_cache@@3PAUst_hash@@A")); > -#else > +#elif MYSQL_VERSION_ID < 100103 > spd_db_att_LOCK_xid_cache = (pthread_mutex_t *) > #if MYSQL_VERSION_ID < 50500 > GetProcAddress(current_module, > @@ -6289,7 +6291,7 @@ int spider_db_init( > spd_db_att_xid_cache_split_num = &opt_xid_cache_split_num; > spd_db_att_LOCK_xid_cache = LOCK_xid_cache; > spd_db_att_xid_cache = xid_cache; > -#else > +#elif MYSQL_VERSION_ID < 100103 > spd_db_att_LOCK_xid_cache = &LOCK_xid_cache; > spd_db_att_xid_cache = &xid_cache; > #endif > diff --git a/storage/spider/spd_trx.cc b/storage/spider/spd_trx.cc > index a66fa5a..1b02bb8 100644 > --- a/storage/spider/spd_trx.cc > +++ b/storage/spider/spd_trx.cc > @@ -38,11 +38,13 @@ > #include "spd_ping_table.h" > #include "spd_malloc.h" > > +#if MYSQL_VERSION_ID < 100103 > #ifdef XID_CACHE_IS_SPLITTED > extern uint *spd_db_att_xid_cache_split_num; > #endif > extern pthread_mutex_t *spd_db_att_LOCK_xid_cache; > extern HASH *spd_db_att_xid_cache; > +#endif > extern struct charset_info_st *spd_charset_utf8_bin; > > extern handlerton *spider_hton_ptr; > @@ -1641,6 +1643,13 @@ int spider_xa_lock( > int error_num; > const char *old_proc_info; > DBUG_ENTER("spider_xa_lock"); > +#if MYSQL_VERSION_ID >= 100103 > + old_proc_info = thd_proc_info(thd, "Locking xid by Spider"); > + error_num= 0; > + if (xid_cache_insert(thd, xid_state)) > + error_num= thd->get_stmt_da()->sql_errno() == ER_XAER_DUPID ? > + ER_SPIDER_XA_LOCKED_NUM : HA_ERR_OUT_OF_MEM; > +#else > #ifdef SPIDER_HAS_HASH_VALUE_TYPE > my_hash_value_type hash_value = my_calc_hash(spd_db_att_xid_cache, > (uchar*) xid_state->xid.key(), xid_state->xid.key_length()); > @@ -1699,6 +1708,7 @@ int spider_xa_lock( > #else > pthread_mutex_unlock(spd_db_att_LOCK_xid_cache); > #endif > +#endif > thd_proc_info(thd, old_proc_info); > DBUG_RETURN(error_num); > } > @@ -1709,6 +1719,10 @@ int spider_xa_unlock( > THD *thd = current_thd; > const char *old_proc_info; > DBUG_ENTER("spider_xa_unlock"); > +#if MYSQL_VERSION_ID >= 100103 > + old_proc_info = thd_proc_info(thd, "Unlocking xid by Spider"); > + xid_cache_delete(thd, xid_state); > +#else > #if defined(SPIDER_HAS_HASH_VALUE_TYPE) && defined(HASH_UPDATE_WITH_HASH_VALUE) > my_hash_value_type hash_value = my_calc_hash(spd_db_att_xid_cache, > (uchar*) xid_state->xid.key(), xid_state->xid.key_length()); > @@ -1738,6 +1752,7 @@ int spider_xa_unlock( > #else > pthread_mutex_unlock(spd_db_att_LOCK_xid_cache); > #endif > +#endif > thd_proc_info(thd, old_proc_info); > DBUG_RETURN(0); > } > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits Regards, Sergei

2 1

Re: [Maria-developers] b723778: MDEV-6997: SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog
by Sergei Golubchik 13 Mar '15

13 Mar '15

Hi, Sanja! Ok to push, thanks. But see one confusing typo below. On Mar 13, sanja(a)mariadb.com wrote: > revision-id: b7237786f5b8e74ba9558db8325d29a64f1a1d9b > parent(s): ba3573cae8f0d269452cc6213f1a8243e455830e > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-03-13 16:32:47 +0100 > message: > > MDEV-6997: SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog > > Problem was in reinitialization of first_successful_insert_id_in_prev_stmt_for_binlog after setting variables. > > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 0837a70..41df891 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -2743,6 +2743,18 @@ static bool do_execute_sp(THD *thd, sp_head *sp) > lex->restore_set_statement_var(); > goto error; > } > + /* > + The value of last_insert_id is remembered in THD to be written to binlog Hmm, I thought you'll put it in the commit comment. But ok, having it in the code is fine too, whatever you prefer. > + when it's used *the first time* in the statement. But SET STATEMENT > + must read the old value of last_insert_id to be able to restore it at > + the end. This should not count at "reading of last_insert_id" and > + should not remember last_insert_id for binlog. That is, it should set typo: it should *reset* (or *clear*) not *set* > + stmt_depends_on_first_successful_insert_id_in_prev_stmt flag. > + */ > + if (!thd->in_sub_stmt) > + { > + thd->stmt_depends_on_first_successful_insert_id_in_prev_stmt= 0; > + } > } Regards, Sergei

1 0

Re: [Maria-developers] 3c941d4: MDEV-5214 Status variables for number of global/db/table/column/role grants
by Sergei Golubchik 13 Mar '15

13 Mar '15

Hi, Vicențiu! That's pretty good, thanks! Although I would like to suggest a somewhat different approach, see below. And there are few minor comments too. On Mar 13, vicentiu(a)mariadb.org wrote: > revision-id: 3c941d471b79ba5d9939a4a1ac61ce5ed8bebaef > parent(s): 197afb413fcc9f06b5e5e6ef41ce980d108b354f > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-03-13 17:45:07 +0200 > message: > > MDEV-5214 Status variables for number of global/db/table/column/role grants > > Implemented the status variables for use with the feedback plugin. > > --- > mysql-test/suite/plugins/r/acl_statistics.result | 107 +++++++++++++++++++++++ > mysql-test/suite/plugins/t/acl_statistics.test | 70 +++++++++++++++ > sql/mysqld.cc | 34 +++++++ > sql/sql_acl.cc | 34 +++++++ > sql/sql_acl.h | 10 +++ > 5 files changed, 255 insertions(+) > > diff --git a/mysql-test/suite/plugins/t/acl_statistics.test b/mysql-test/suite/plugins/t/acl_statistics.test > new file mode 100644 > index 0000000..e10d907 > --- /dev/null > +++ b/mysql-test/suite/plugins/t/acl_statistics.test > @@ -0,0 +1,70 @@ > +# Test case for validating acl statistics for the feedback plugin. > +--source include/not_embedded.inc > +if (`select count(*) = 0 from information_schema.plugins where plugin_name = 'feedback' and plugin_status='active'`) > +{ > + --skip Feedback plugin is not active > +} Don't bother using feedback plugin for this test. There is nothing in the patch that depends on or uses feedback plugin, so there's no need to make the test depending on it. Please, use SHOW STATUS (or SELECT ... FROM INFORMATION_SCHEMA.GLOBAL_STATUS). And then move the test out of plugins suite. > + > +# First get a baseline of the initial statistics. ... > diff --git a/mysql-test/suite/plugins/r/acl_statistics.result b/mysql-test/suite/plugins/r/acl_statistics.result > new file mode 100644 > index 0000000..dad37bf > --- /dev/null > +++ b/mysql-test/suite/plugins/r/acl_statistics.result > @@ -0,0 +1,107 @@ > +SELECT * FROM information_schema.feedback > +WHERE variable_name like '%Acl%'; > +VARIABLE_NAME VARIABLE_VALUE > +ACL_COUNT_COLUMN_GRANTS 0 > +ACL_COUNT_DATABASE_GRANTS 2 > +ACL_COUNT_FUNCTION_GRANTS 0 > +ACL_COUNT_PROCEDURE_GRANTS 0 > +ACL_COUNT_PROXY_USERS 2 > +ACL_COUNT_ROLE_MAPPINGS 0 > +ACL_COUNT_ROLES 0 > +ACL_COUNT_TABLE_GRANTS 0 > +ACL_COUNT_USERS 4 > +SELECT count(*) COLUMN_GRANTS_COUNT from mysql.columns_priv; > +COLUMN_GRANTS_COUNT > +0 > +SELECT count(*) DATABASE_GRANTS_COUNT from mysql.db; > +DATABASE_GRANTS_COUNT > +2 > +SELECT count(*) FUNCTION_GRANTS_COUNT from mysql.procs_priv where routine_type='FUNCTION'; > +FUNCTION_GRANTS_COUNT > +0 > +SELECT count(*) PROCEDURE_GRANTS_COUNT from mysql.procs_priv where routine_type='PROCEDURE'; > +PROCEDURE_GRANTS_COUNT > +0 > +SELECT count(*) PROXY_USERS from mysql.proxies_priv; > +PROXY_USERS > +2 > +SELECT count(*) ROLE_GRANTS_COUNT from mysql.user where is_role='Y'; > +ROLE_GRANTS_COUNT > +0 > +SELECT count(*) ROLE_MAPPINGS_COUNT from mysql.roles_mapping; > +ROLE_MAPPINGS_COUNT > +0 > +SELECT count(*) TABLE_GRANTS_COUNT from mysql.tables_priv; > +TABLE_GRANTS_COUNT > +0 > +SELECT count(*) USERS_COUNT from mysql.user where is_role='N'; > +USERS_COUNT > +4 > +CREATE USER u1; > +CREATE ROLE r1; > +CREATE ROLE r2; > +GRANT PROXY ON root TO u1; > +GRANT SELECT ON *.* to u1; > +GRANT SELECT ON *.* to r1; > +GRANT DELETE ON mysql.* to u1; > +GRANT DELETE ON mysql.* to r1; > +GRANT INSERT ON mysql.user to u1; > +GRANT INSERT ON mysql.user to r1; > +GRANT UPDATE (host) ON mysql.user to u1; > +GRANT UPDATE (host) ON mysql.user to r1; > +GRANT r1 to u1; > +GRANT r2 to r1; > +create procedure mysql.test_proc (OUT param1 INT) > +begin > +select COUNT(*) into param1 from mysql.roles_mapping; > +end| > +GRANT EXECUTE ON PROCEDURE mysql.test_proc TO r1; > +GRANT EXECUTE ON PROCEDURE mysql.test_proc TO u1; > +CREATE FUNCTION mysql.test_func (param INT) RETURNS INT > +RETURN (SELECT COUNT(*) FROM mysql.user); > +GRANT EXECUTE ON FUNCTION mysql.test_func TO r1; > +GRANT EXECUTE ON FUNCTION mysql.test_func TO u1; > +SELECT * FROM information_schema.feedback > +WHERE variable_name like '%Acl%'; > +VARIABLE_NAME VARIABLE_VALUE > +ACL_COUNT_COLUMN_GRANTS 2 > +ACL_COUNT_DATABASE_GRANTS 4 > +ACL_COUNT_FUNCTION_GRANTS 2 > +ACL_COUNT_PROCEDURE_GRANTS 2 > +ACL_COUNT_PROXY_USERS 3 > +ACL_COUNT_ROLE_MAPPINGS 4 > +ACL_COUNT_ROLES 2 > +ACL_COUNT_TABLE_GRANTS 2 > +ACL_COUNT_USERS 5 > +SELECT count(*) COLUMN_GRANTS_COUNT from mysql.columns_priv; > +COLUMN_GRANTS_COUNT > +2 > +SELECT count(*) DATABASE_GRANTS_COUNT from mysql.db; > +DATABASE_GRANTS_COUNT > +4 > +SELECT count(*) FUNCTION_GRANTS_COUNT from mysql.procs_priv where routine_type='FUNCTION'; > +FUNCTION_GRANTS_COUNT > +2 > +SELECT count(*) PROCEDURE_GRANTS_COUNT from mysql.procs_priv where routine_type='PROCEDURE'; > +PROCEDURE_GRANTS_COUNT > +2 > +SELECT count(*) PROXY_USERS from mysql.proxies_priv; > +PROXY_USERS > +3 > +SELECT count(*) ROLE_GRANTS_COUNT from mysql.user where is_role='Y'; > +ROLE_GRANTS_COUNT > +2 > +SELECT count(*) ROLE_MAPPINGS_COUNT from mysql.roles_mapping; > +ROLE_MAPPINGS_COUNT > +4 Please, swap these two selects (ROLE_GRANTS_COUNT and ROLE_MAPPINGS_COUNT) to have values go in the same order as in the I_S table (it's easier to compare numbers that way). Same for the previous set of selects. > +SELECT count(*) TABLE_GRANTS_COUNT from mysql.tables_priv; > +TABLE_GRANTS_COUNT > +2 > +SELECT count(*) USERS_COUNT from mysql.user where is_role='N'; > +USERS_COUNT > +5 > +DROP PROCEDURE mysql.test_proc; > +DROP FUNCTION mysql.test_func; > +DROP ROLE r2; > +DROP ROLE r1; > +DROP USER u1; > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index aa85a02..a7be18f 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -8149,6 +8149,39 @@ int show_threadpool_idle_threads(THD *thd, SHOW_VAR *var, char *buff, > } > #endif > > +int show_acl_statistics(THD *thd, SHOW_VAR *var, char *buff, > + enum enum_var_type scope) > +{ > + > + var->type= SHOW_ARRAY; > + var->value= buff; > + > + SHOW_VAR *v= (SHOW_VAR *)buff; > + static ACL_statistics acl_stats; > + acl_stats= get_acl_statistics(thd); > + static SHOW_VAR statistics_array[]= { > + {"column_grants", (char *)&acl_stats.column_grants, SHOW_ULONG}, > + {"database_grants", (char *)&acl_stats.database_grants, SHOW_ULONG}, > + {"function_grants", (char *)&acl_stats.function_grants, SHOW_ULONG}, > + {"procedure_grants", (char *)&acl_stats.procedure_grants, SHOW_ULONG}, > + {"proxy_users", (char *)&acl_stats.proxy_users, SHOW_ULONG}, > + {"role_mappings", (char *)&acl_stats.role_mappings, SHOW_ULONG}, rename to "role_grants" please. > + {"roles", (char *)&acl_stats.roles, SHOW_ULONG}, > + {"table_grants", (char *)&acl_stats.table_grants, SHOW_ULONG}, > + {"users", (char *)&acl_stats.users, SHOW_ULONG}, > + {NullS, NullS, SHOW_LONG} > + }; > + v->name= "count"; the name doesn't matter, no need to set it. > + v->value = statistics_array; > + v->type= SHOW_ARRAY; > + v++; > + v->name= NullS; > + v->value= NullS; > + v->type= SHOW_LONG; > + > + return 0; > +} > + > /* > Variables shown by SHOW STATUS in alphabetical order > */ > @@ -8157,6 +8190,7 @@ SHOW_VAR status_vars[]= { > {"Aborted_clients", (char*) &aborted_threads, SHOW_LONG}, > {"Aborted_connects", (char*) &aborted_connects, SHOW_LONG}, > {"Access_denied_errors", (char*) offsetof(STATUS_VAR, access_denied_errors), SHOW_LONG_STATUS}, > + {"Acl", (char*) &show_acl_statistics, SHOW_FUNC}, > {"Binlog_bytes_written", (char*) offsetof(STATUS_VAR, binlog_bytes_written), SHOW_LONGLONG_STATUS}, > {"Binlog_cache_disk_use", (char*) &binlog_cache_disk_use, SHOW_LONG}, > {"Binlog_cache_use", (char*) &binlog_cache_use, SHOW_LONG}, > diff --git a/sql/sql_acl.cc b/sql/sql_acl.cc > index aaa1276..e97d094 100644 > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -10340,6 +10340,14 @@ applicable_roles_insert(ACL_USER_BASE *grantee, ACL_ROLE *role, void *ptr) > return 0; > } > > +static my_bool count_column_privileges(void *grant_table, > + void *current_count) > +{ > + HASH hash_columns = ((GRANT_TABLE *)grant_table)->hash_columns; > + *(ulong *) current_count+= hash_columns.records; > + return 0; > +} > + > #else > bool check_grant(THD *, ulong, TABLE_LIST *, bool, uint, bool) > { > @@ -10347,6 +10355,32 @@ bool check_grant(THD *, ulong, TABLE_LIST *, bool, uint, bool) > } > #endif /*NO_EMBEDDED_ACCESS_CHECKS */ > > +ACL_statistics get_acl_statistics(THD* thd) > +{ > + ACL_statistics result; > + bzero(&result, sizeof(result)); > +#ifndef NO_EMBEDDED_ACCESS_CHECKS > + mysql_rwlock_rdlock(&LOCK_grant); > + mysql_mutex_lock(&acl_cache->lock); > + > + result.users= acl_users.elements; > + result.roles= acl_roles.records; > + result.database_grants= acl_dbs.elements; > + result.function_grants= proc_priv_hash.records; > + result.procedure_grants= proc_priv_hash.records; > + result.proxy_users= acl_proxy_users.elements; > + result.role_mappings= acl_roles_mappings.records; > + result.table_grants= column_priv_hash.records; > + my_hash_iterate(&column_priv_hash, count_column_privileges, > + &result.column_grants); > + > + mysql_mutex_unlock(&acl_cache->lock); > + mysql_rwlock_unlock(&LOCK_grant); > + > +#endif > + return result; > +} > + > int fill_schema_enabled_roles(THD *thd, TABLE_LIST *tables, COND *cond) > { > TABLE *table= tables->table; > diff --git a/sql/sql_acl.h b/sql/sql_acl.h > index 55b00a9..3abf5d7 100644 > --- a/sql/sql_acl.h > +++ b/sql/sql_acl.h > @@ -406,4 +406,14 @@ int acl_set_default_role(THD *thd, const char *host, const char *user, > extern ulong role_global_merges, role_db_merges, role_table_merges, > role_column_merges, role_routine_merges; > #endif > +/** > + Specify which statistical information (counts) to retrieve from > + the ACL data structures. > +*/ > +struct ACL_statistics > +{ > + ulong column_grants, database_grants, function_grants, procedure_grants, > + proxy_users, role_mappings, roles, table_grants, users; > +}; > +ACL_statistics get_acl_statistics(THD *thd); > #endif /* SQL_ACL_INCLUDED */ I would do it slightly differently. No ACL_statistics structure and no get_acl_statistics function, but instead I'd use SHOW_ARRAY in mysqld.cc: {"Acl", (char*) &show_acl_statistics, SHOW_ARRAY}, and in sql_acl.cc I'd have an array static SHOW_VAR statistics_array[]= { {"column_grants", (char *)&get_column_grants, SHOW_SIMPLE_FUNC}, {"database_grants", (char *)&acl_dbs.elements, SHOW_ULONG}, {"function_grants", (char *)&proc_priv_hash.records, SHOW_ULONG}, {"procedure_grants", (char *)&proc_priv_hash.records, SHOW_ULONG}, {"proxy_users", (char *)&acl_proxy_users.elements, SHOW_ULONG}, {"role_grants", (char *)&acl_roles_mappings.records, SHOW_ULONG}, {"roles", (char *)&acl_roles.records, SHOW_ULONG}, {"table_grants", (char *)&column_priv_hash.records, SHOW_ULONG}, {"users", (char *)&acl_users.elements, SHOW_ULONG}, {NullS, NullS, SHOW_LONG} }; That is, only column_grants need a function call (with mutex locks), and it's SHOW_SIMPLE_FUNC, not SHOW_FUNC. The different is that a typical (for example) SHOW STATUS LIKE '%sort%' will have to invoke all SHOW_FUNC functions, because otherwise it cannot know names of the variables and cannot match them. But SHOW_SIMPLE_FUNC never returns a SHOW_ARRAY, so it can be matched without a function call (so, no mutex lock unless the user specifically asked for Acl_column_grants value). Also, status variables are allowed to be "slightly imprecise", so they're often incremented without a mutex. That is, you aren't required to protect them here with a mutex either. Regards, Sergei

1 0

[Maria-developers] MDEV-6566 Different INSERT behaviour on bad bytes with and without character set conversion
by Alexander Barkov 13 Mar '15

13 Mar '15

Hi Sergei, Please review a patch for MDEV-6566. Thanks.

2 5

[Maria-developers] Enabling feedback pluging for MariaDB 10.1.4
by Michael Widenius 12 Mar '15

12 Mar '15

Hi! We had originally planned to enable the feedback plugin by default for the Alpha and Beta stages of MariaDB 10.1, but we forgot to do this for the alpha so I suggested Sergei today that we should enable it for the beta period of MariaDB 10.0 We agreed that before doing this we would have a discussion on the maria developer list to explain why we would like to do this. The reason we would like to enable it is to get information about which features people are testing and using in MariaDB 10.1, so that we can concentrate our testing and bug fixing during the beta phase for those areas that people are actually using. This would help our development work a lot and would also help us to plan for MariaDB 10.2 development. Anyone will be able to disable the feedback plugin by adding: --feedback=OFF to their my.cnf file. In MariaDB 10.1 gamma/release we would make it default OFF again. We will of course inform everyone about this change, including how to disable the feedback, in the MariaDB changelog and release notes. We do of course hope that as many as possible will have it on, even after gamma, to help us with our development work! Information about the MariaDB feedback plugin and the statistics it provides can be found at: http://mariadb.org/feedback_plugin https://mariadb.com/kb/feedback-plugin As most MariaDB users should know, the feedback is totally anonymous and no private or sensitive information is being sent. Any comments, suggestions or recommendations? Regards, Michael Widenius Creator of MySQL and MariaDB

10 14

Re: [Maria-developers] 6c772ae: MDEV-6956:SET STATEMENT default_master_connection = ... has no effect
by Sergei Golubchik 12 Mar '15

12 Mar '15

Hi, Sanja! On Mar 06, sanja(a)mariadb.com wrote: > revision-id: 6c772ae62a0a43ea227f491509c02efb99c5ce92 > parent(s): da181fee4ec849985b15a758c6b26058a0f5e318 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-03-06 15:51:51 +0100 > message: > > MDEV-6956:SET STATEMENT default_master_connection = ... has no effect > > the problem was in assigning default value during parsing. Ok to push, but see below. > diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy > index 8025340..8255306 100644 > --- a/sql/sql_yacc.yy > +++ b/sql/sql_yacc.yy > @@ -2445,7 +2445,9 @@ optional_connection_name: > /* empty */ > { > LEX *lex= thd->lex; > - lex->mi.connection_name= thd->variables.default_master_connection; > + lex->mi.connection_name.str= NullS; > + lex->mi.connection_name.length= 0; > + //thd->variables.default_master_connection; you've forgot to remove this commented-out line. and prefer to use null_lex_str: lex->mi.connection_name= null_lex_str; Regards, Sergei

2 2

Re: [Maria-developers] 7ceff99: MDEV-6954: SET STATEMENT rand_seedX = ...FOR ... makes the next rand() to return 0
by Sergei Golubchik 11 Mar '15

11 Mar '15

Hi, Sanja! On Mar 11, sanja(a)mariadb.com wrote: > revision-id: 7ceff99ff25b74bb188848ce0e5f9e2f1ddac3d0 > parent(s): 9f4ee16bf351ea2969d73abcdea92e70538c723c > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-03-11 11:02:13 +0100 > message: > > MDEV-6954: SET STATEMENT rand_seedX = ...FOR ... makes the next rand() to return 0 > > The variables now return real values. They can't be made usual variables because they do not have DEFAULT value. > > diff --git a/mysql-test/suite/sys_vars/inc/sysvars_server.inc b/mysql-test/suite/sys_vars/inc/sysvars_server.inc > index fb6121d..3a9a312 100644 > --- a/mysql-test/suite/sys_vars/inc/sysvars_server.inc > +++ b/mysql-test/suite/sys_vars/inc/sysvars_server.inc > @@ -17,6 +17,7 @@ select * from information_schema.system_variables > where variable_name not like 'aria%' and > variable_name not like 'debug%' and > variable_name not like 'wsrep%' and > + variable_name not like 'rand_seed%%' and 1. why two %% ? :) 2. there are only two variables here, better list them explicilty in the "not in" list 3. if you remove variables from the output here, please add them to the select below. > variable_name not in ( > 'have_openssl', > 'have_symlink', Regards, Sergei

1 0

Re: [Maria-developers] 60c1dc1: MDEV-6997: SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog
by Sergei Golubchik 11 Mar '15

11 Mar '15

Hi, Sanja! On Feb 25, sanja(a)mariadb.com wrote: > revision-id: 60c1dc1ab24bfe9b3f4a898fe5e7cb070ee02cf7 > parent(s): d0d6284cab70af148269d95744f615454cac24bb > committer: Oleksandr Byelkin > branch nick: work-maria-10.1-MDEV-6997-real > timestamp: 2015-02-25 19:00:57 +0100 > message: > > MDEV-6997: SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog > > Problem was in reinitialization of > first_successful_insert_id_in_prev_stmt_for_binlog after setting > variables. > > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 5af700b..54abfd0 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -2728,6 +2728,10 @@ static bool do_execute_sp(THD *thd, sp_head *sp) > my_error(ER_WRONG_ARGUMENTS, MYF(0), "SET"); > goto error; > } > + if (!thd->in_sub_stmt) /* stored functions and triggers are a special case */ > + { > + thd->stmt_depends_on_first_successful_insert_id_in_prev_stmt= 0; > + } > } This seems to be a pretty complicated matter, and your comment isn't very helpful. Try this: The value of last_insert_id is remembered in THD to be written to binlog when it's used *the first time* in the statement. But SET STATEMENT must read the old value of last_insert_id to be able to restore it at the end. This should not count at "reading of last_insert_id" and should not remember last_insert_id for binlog. That is, it should set stmt_depends_on_first_successful_insert_id_in_prev_stmt flag. And try the test case where SET STATEMENT last_insert_id is used inside a trigger or a stored function. I don't think you handle this case correctly. Try both cases, when stmt_depends... is 0 and is 1 at the point of this if(). I suspect you should not set stmt_depends_on_first_successful_insert_id_in_prev_stmt to 0, but you need to make sure it didn't change. That is, you need to set it to its old value (which may or may not be 0). Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 828a7b6: MDEV-6858: enforce_storage_engine option
by Sergei Golubchik 11 Mar '15

11 Mar '15

Hi, Jan! This looks good, thanks! There's just one strange thing I've noticed, see sysvars_server_notembedded test below. I don't understand why it's happening, could you investigate, please? On Mar 10, Jan Lindström wrote: > revision-id: 828a7b67768c7e7a72c2a687f5a3ff77bc61536b > parent(s): f7d196bb2e605766668895027c48728f03803734 > committer: Jan Lindström > branch nick: 10.1-innodb > timestamp: 2015-03-10 08:28:51 +0200 > message: > > MDEV-6858: enforce_storage_engine option > > Merge from Percona Server enforced use of a specific storage engine > authored by Stewart Smith. > > Modified to be session variable and modifiable only by SUPER. Use > similar implementation as default_storage_engine. > > diff --git a/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result b/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result > index 83c0196..bf8f868 100644 > --- a/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result > +++ b/mysql-test/suite/sys_vars/r/sysvars_server_notembedded.result > @@ -721,6 +721,20 @@ NUMERIC_BLOCK_SIZE NULL > ENUM_VALUE_LIST OFF,ON > READ_ONLY NO > COMMAND_LINE_ARGUMENT OPTIONAL > +VARIABLE_NAME ENFORCE_STORAGE_ENGINE > +SESSION_VALUE > +GLOBAL_VALUE NULL This looks strange. Why session value is empty string, but global value is NULL? I believe they should be identical, shouldn't they? Preferrably, both should be empty string - I don't think we have system variables that can be NULL. > +GLOBAL_VALUE_ORIGIN COMPILE-TIME > +DEFAULT_VALUE NULL > +VARIABLE_SCOPE SESSION ONLY > +VARIABLE_TYPE VARCHAR > +VARIABLE_COMMENT Force the use of a storage engine for new tables > +NUMERIC_MIN_VALUE NULL > +NUMERIC_MAX_VALUE NULL > +NUMERIC_BLOCK_SIZE NULL > +ENUM_VALUE_LIST NULL > +READ_ONLY NO > +COMMAND_LINE_ARGUMENT NULL > VARIABLE_NAME ERROR_COUNT > SESSION_VALUE 0 > GLOBAL_VALUE NULL > diff --git a/mysql-test/t/enforce_storage_engine.test b/mysql-test/t/enforce_storage_engine.test > new file mode 100644 > index 0000000..80839e2 > --- /dev/null > +++ b/mysql-test/t/enforce_storage_engine.test > @@ -0,0 +1,64 @@ > +-- source include/have_innodb.inc You can keep it this way, but I'd recommend to change to either have_xtradb.inc or (better) not use innodb at all and test with myisam and memory engines. with have_innodb.inc the test will be run twice - for innodb and for xtradb, which is a waste of time, because it doesn't do anything engine-specific here. > +-- source include/not_embedded.inc > + > +--disable_warnings > +drop table if exists t1; > +--enable_warnings Regards, Sergei

2 1

Re: [Maria-developers] [Commits] Rev 4382: MDEV-6892: WHERE does not apply in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-6892/
by Sergey Petrunia 11 Mar '15

11 Mar '15

Hi Sanja, Please find my feedback below. We should discuss it. On Fri, Dec 19, 2014 at 01:24:12PM +0000, sanja(a)askmonty.org wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-6892/ > > ------------------------------------------------------------ > revno: 4382 > revision-id: sanja(a)askmonty.org-20141219132350-6bo1g7q6gbivqdky > parent: svoj(a)mariadb.org-20141201105829-ctaoe194abtorhz2 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-6892 > timestamp: Fri 2014-12-19 14:23:50 +0100 > message: > MDEV-6892: WHERE does not apply > > Taking into account implicit dependence of constant view field from nullable table of left join added. > > Fixed finding real table to check if ut turned to NULL (materialized view & derived taken into account) ... > === modified file 'sql/item.cc' > --- a/sql/item.cc 2014-10-06 17:53:55 +0000 > +++ b/sql/item.cc 2014-12-19 13:23:50 +0000 > @@ -9790,12 +9790,36 @@ void Item_ref::update_used_tables() > (*ref)->update_used_tables(); > } > > +void Item_direct_view_ref::update_used_tables() > +{ > + if (view->is_inner_table_of_outer_join()) > + { > + null_ref_table= NULL; > + check_null_ref(); update_used_tables() is called during optimization. Why does it call check_null_ref() which may check null_ref_table->null_row? Is check_null_ref() function an execution-time function (and so it computes "current" value of an item) or is it an optimization-time function (and so it computes static attributes and can be called at any point in the query) It looks like it's a bit of both, which is really confusing. Could you please clarify? check_null_ref() was introduced by you in another views+outer joins bugfix. Can we get it documented? > + } > + Item_direct_ref::update_used_tables(); > +} Overall, I don't understand why some checks are in used_tables() and some are in update_used_tables(). Could you clarify? > + > table_map Item_direct_view_ref::used_tables() const > { > + TABLE *null_ref= null_ref_table; > + > + if (view->is_inner_table_of_outer_join()) > + { > + if (null_ref == NULL) > + null_ref= view->get_real_join_table(); > + else if (null_ref == NO_NULL_TABLE) > + null_ref= NULL; > + } > + else > + null_ref= NULL; > + > return get_depended_from() ? > OUTER_REF_TABLE_BIT : > ((view->is_merged_derived() || view->merged || !view->table) ? > - (*ref)->used_tables() : > + ((*ref)->used_tables() ? > + (*ref)->used_tables() : > + (null_ref ? null_ref->map : (table_map)0 )) : > view->table->map); Two-level nesting of conditional expressions is too complicated. Please change into 'if' statement and a comment about what's going on. How can Item_direct_view_ref() deped on an outer table?? > } > > > === modified file 'sql/item.h' > --- a/sql/item.h 2014-11-18 14:42:40 +0000 > +++ b/sql/item.h 2014-12-19 13:23:50 +0000 > @@ -3319,7 +3319,8 @@ class Item_direct_view_ref :public Item_ > { > if (null_ref_table == NULL) > { > - if (!(null_ref_table= view->get_real_join_table())) > + if (!view->is_inner_table_of_outer_join() || > + !(null_ref_table= view->get_real_join_table())) > null_ref_table= NO_NULL_TABLE; > } > if (null_ref_table != NO_NULL_TABLE && null_ref_table->null_row) > @@ -3329,6 +3330,7 @@ class Item_direct_view_ref :public Item_ > } > return FALSE; > } > + > public: > Item_direct_view_ref(Name_resolution_context *context_arg, Item **item, > const char *table_name_arg, > @@ -3353,8 +3355,10 @@ public: > bool subst_argument_checker(uchar **arg); > Item *equal_fields_propagator(uchar *arg); > Item *replace_equal_field(uchar *arg); > - table_map used_tables() const; > + table_map used_tables() const; > + void update_used_tables(); > table_map not_null_tables() const; > + bool const_item() const { return used_tables() == 0; } > bool walk(Item_processor processor, bool walk_subquery, uchar *arg) > { > return (*ref)->walk(processor, walk_subquery, arg) || > > === modified file 'sql/table.cc' > --- a/sql/table.cc 2014-10-29 10:22:48 +0000 > +++ b/sql/table.cc 2014-12-19 13:23:50 +0000 The function get_real_join_table() lacks comments, which makes it difficult to review. Do I understand correctly that its action can be described by this comment: /* @brief Given a merged view (or a merged derived table), find its first* base** table. @detail (*) first means as defined in the syntax (**) base means we need a physical table, one that has a bit in table->map and is present in select_lex->leaf_tables. Example: t1 join ( (select * from t2, t3 ) as derivedA join (select * from t5, t6) as derivedC ) as derivedB here, derivedB->get_real_join_table()="t2" */ > @@ -5012,7 +5012,8 @@ TABLE *TABLE_LIST::get_real_join_table() > TABLE_LIST *tbl= this; > while (tbl->table == NULL || tbl->table->reginfo.join_tab == NULL) I'm quite surprised that joins are run over tables that don't have reginfo.join_tab set appropriately... > { > - if (tbl->view == NULL && tbl->derived == NULL) > + if ((tbl->view == NULL && tbl->derived == NULL) || > + tbl->is_materialized_derived()) I'm wondering why part of conditions are in while(...) and the other part is here. > break; > /* we do not support merging of union yet */ > DBUG_ASSERT(tbl->view == NULL || > The code below this line looks bizarre (and it is still from your recent fixes to VIEWs): { List_iterator_fast<TABLE_LIST> ti; { List_iterator_fast<TABLE_LIST> ti(tbl->view != NULL ? why define 'ti' and then immediately redefine it? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

Re: [Maria-developers] f954bb7: MDEV-7671: Cache VIEW definitions in the TDC
by Sergei Golubchik 11 Mar '15

11 Mar '15

Hi, Sanja! On Mar 10, sanja(a)mariadb.com wrote: > revision-id: f954bb7fdc527cf816253fe0e7adb4239c368624 > parent(s): f7d196bb2e605766668895027c48728f03803734 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-03-10 12:52:45 +0100 > message: > > MDEV-7671: Cache VIEW definitions in the TDC > > (changes of backported patch are very small: strlen removed, error > processing fixed, view open statistics added) Ok to push Regards, Sergei

1 0

[Maria-developers] GSOC 2015: Support for popular formats on Dynamic columns.
by arlene seuleu 11 Mar '15

11 Mar '15

Hi I am Arlene Flavie a software Engineering student and I wish to make my contribution to opensource through Mariadb. I have build mariadb from a git clone and ran the tests. I am interested in working on adding routines to import and export popular data formats to and from dynamic columns. I am currently studying the dynamic column data structures in mysql/ma_dyncol.** and I think what Oleksandr Byeklin proposed makes sense to me. Thats using methods like xxx_init() and xxx_named() to play with the old dynamic column blob format. I will be applying to work on this task for Gsoc 2015 and im hoping to learn much in open source development. Cheers.

2 1

[Maria-developers] Interest in GSoc
by Acha Bill 11 Mar '15

11 Mar '15

Hello, I am Acha Bill, Computer Engineering, University of Buea, Cameroon. Second year undergraduate. I am very much interested in the project; Import and export popular data formats from and to dynamic columns. for Gsoc 15. I have experience with C. Any pointers as to what next will be appreciated. Thanks.

2 1

Re: [Maria-developers] [Maria-discuss] Enabling feedback pluging for MariaDB 10.1.4
by Justin Swanhart 11 Mar '15

11 Mar '15

It tells you how much a sample used and you don't know what fraction of the total that represents, or if their usage is representative of the larger base. I maintain they are not meaningful but you can feel free to disagree. Sent from my iPhone > On Mar 10, 2015, at 7:42 PM, Michael Widenius <michael.widenius(a)gmail.com> wrote: > > Hi! > > <cut> > >> I agree with Kristian. Given the way it works, the statistics are really meaningless and I feel you shouldn't drive important choices based on bad statistics. > > From a statistics point of view, the automatic feedback will tell us a > lot about how people use MariaDB and is far from meaningless! > (We only need a small statistical sample to know how the majority is > using the server). > > The most important things for our developers, that the phone home > feature will tell us, are probably: > - Features that are used (and how much they are used) > - Features that not used. > - Combinations of features used. > - The stability of the servers. > - How often upgrades are done > > This will allow us to better concentrate the few development resources > on features that are important to our users. > > In the past, our main problem for allocating resources has always been > "does anyone really use or care about this". Now we finally will get > some information to make these kind of decisions easier. > > Regards, > Monty

2 1

[Maria-developers] GSOC 2015 :UDFs returning arrays
by Blessing Atie 10 Mar '15

10 Mar '15

Hi My name is Blessing Atie and i would love to participate in the Google summer of code 2015 under Mariadb. I am interested in the project UDF returning arrays. I have build mariadb from source and and i also ran the test suites. I am currently studing the sql/sql.** files to understand UDF's and i also downloaded some ebook on mysql internals and mysql plugin development which im reading while hoping to find a breakthrough on this project in them. I would love to know if there are any bugs related to this task on JIRA I could work on as a means of preparing for the project. Please give me the link. Regards Blessing.

1 0

Re: [Maria-developers] [Commits] 83659a6: MDEV-7006 MDEV-7007: SET STATEMENT and slow log
by Sergei Golubchik 10 Mar '15

10 Mar '15

Hi, Sanja! On Feb 17, sanja(a)mariadb.com wrote: > revision-id: 83659a68642da2eb6e9327f17a0ef730f512aa96 > parent(s): 3e2849d2a01b06a61407b00989c3f981e62dd183 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-02-17 12:54:51 +0100 > message: > > MDEV-7006 MDEV-7007: SET STATEMENT and slow log > fixed embedded server tests > MDEV-7009: SET STATEMENT min_examined_row_limit has no effect > MDEV-6948:SET STATEMENT gtid_domain_id = ... FOR has no effect (same for gtid_seq_no and server_id) > > old values of SET STATENENT variables now saved in its own Query_arena and restored later Looks good to me. I didn't check, though, whether you've put every restore correctly. See minor comments below: > diff --git a/mysql-test/t/set_statement_notembedded_binlog.test b/mysql-test/t/set_statement_notembedded_binlog.test > new file mode 100644 > index 0000000..c9c2334 > --- /dev/null > +++ b/mysql-test/t/set_statement_notembedded_binlog.test > @@ -0,0 +1,22 @@ > +--source include/have_log_bin.inc > +--source include/not_embedded.inc > + > +--disable_warnings > +drop table if exists t1; > +drop view if exists t1; > +--enable_warnings This was useful in our early MySQL days, but it's not anymore. I've stopped adding these drop...if exists at the beginning of test files a couple of years ago. mtr has a after-test check to ensure that no test leaves its tables behind. So one can rely on every test starting clean. > + > +--echo # > +--echo # MDEV-6948: SET STATEMENT gtid_domain_id = ... FOR has no effect > +--echo # (same for gtid_seq_no and server_id) > +--echo # > +reset master; > +create table t1 (i int); > +set gtid_domain_id = 10; > +insert into t1 values (1),(2); > +set statement gtid_domain_id = 20 for insert into t1 values (3),(4); > + > +--replace_column 1 x 2 x 3 x 4 x 5 x > +show binlog events limit 5,5; > + > +drop table t1; > diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc > index 0c1c3b3..ee956ed 100644 > --- a/sql/sql_lex.cc > +++ b/sql/sql_lex.cc > @@ -4223,6 +4224,56 @@ int LEX::print_explain(select_result_sink *output, uint8 explain_flags, > return res; > } > > +void LEX::set_arena_for_set_stmt(Query_arena *backup) > +{ > + DBUG_ENTER("LEX::set_arena_for_set_stmt"); > + DBUG_ASSERT(arena_for_set_stmt== 0); > + if (!mem_root_for_set_stmt) > + { > + mem_root_for_set_stmt= new MEM_ROOT(); > + if (!(mem_root_for_set_stmt)) > + DBUG_VOID_RETURN; What happens in OOM case? You return early, but does the caller know that? Or it'll continue, thinking that everything's ok? > + init_sql_alloc(mem_root_for_set_stmt, ALLOC_ROOT_SET, ALLOC_ROOT_SET, > + MYF(MY_THREAD_SPECIFIC)); > + } > + if (!(arena_for_set_stmt= new Query_arena(mem_root_for_set_stmt, Why are you allocating memory for Query_arena, instead of creating it on mem_root_for_set_stmt? > + Query_arena::STMT_INITIALIZED))) > + DBUG_VOID_RETURN; > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) mem_root_for_set_stmt, > + (ulong) arena_for_set_stmt)); > + thd->set_n_backup_active_arena(arena_for_set_stmt, backup); > + DBUG_VOID_RETURN; > +} > + > + > +void LEX::reset_arena_for_set_stmt(Query_arena *backup) > +{ > + DBUG_ENTER("LEX::reset_arena_for_set_stmt"); > + DBUG_ASSERT(arena_for_set_stmt); > + thd->restore_active_arena(arena_for_set_stmt, backup); > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) arena_for_set_stmt->mem_root, > + (ulong) arena_for_set_stmt)); > + DBUG_VOID_RETURN; > +} > + > + > +void LEX::free_arena_for_set_stmt() > +{ > + DBUG_ENTER("LEX::free_arena_for_set_stmt"); > + if (!arena_for_set_stmt) > + return; > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) arena_for_set_stmt->mem_root, > + (ulong) arena_for_set_stmt)); > + arena_for_set_stmt->free_items(); > + delete(arena_for_set_stmt); > + free_root(mem_root_for_set_stmt, MYF(MY_KEEP_PREALLOC)); > + arena_for_set_stmt= 0; > + DBUG_VOID_RETURN; > +} > + > void LEX::restore_set_statement_var() > { > DBUG_ENTER("LEX::restore_set_statement_var"); > diff --git a/sql/sql_lex.h b/sql/sql_lex.h > index 46d667c..ed3c4a0 100644 > --- a/sql/sql_lex.h > +++ b/sql/sql_lex.h > @@ -2677,10 +2688,22 @@ struct LEX: public Query_tables_list > limit_rows_examined_cnt= ULONGLONG_MAX; > } > > + > + inline void free_set_stmt_mem_root() > + { Please, add DBUG_ASSERT(!is_arena_for_set_stmt()); > + if (mem_root_for_set_stmt) > + { > + free_root(mem_root_for_set_stmt, MYF(0)); > + delete mem_root_for_set_stmt; > + mem_root_for_set_stmt= 0; > + } > + } > + > LEX(); > > virtual ~LEX() > { > + free_set_stmt_mem_root(); > destroy_query_tables_list(); > plugin_unlock_list(NULL, (plugin_ref *)plugins.buffer, plugins.elements); > delete_dynamic(&plugins); Regards, Sergei

2 1

[Maria-developers] GSOC 2015: Indexes on virtual columns
by Sichom Lionel 10 Mar '15

10 Mar '15

Hello, My name is Lionel Sichom, 2nd year undergraduate student at the University of Buea. I am a newbie in Open source community and I am interested in participating at the Google Summer of Code 2015 with MariaDB. I am mostly interested with the project Indexes on virtual columns. As for now I have 5.5.41-MariaDB version and I have already downloded the code, and I am already compiling the code. Can someone please guide me through the steps next to follow. Thanks Lionel Sichom

2 1

[Maria-developers] Question regarding MDEV-7682
by Vicențiu Ciorbaru 10 Mar '15

10 Mar '15

Hi Holyfoot! I've made some changes regarding key_length computation to fix MDEV-6838. Changing this seems to have lead to us discovering another issue outlined in MDEV-7682 (that I've just created). It seems that the spatial key returns a key_length of 0. I've spoken to Sergei Petrunia and we are not sure about this particular case. pack_length returns a bigger number (12). According to the other comments in the code, pack_length also returns the length field associated with the column, but we are only interested in the length of the column field, without any metadata information. The function TABLE:create_key_part_by_field adds the metadata length itself afterwards. Do you have any input on this issue, namely why the key_length is returned as 0 for the LINESTRING column? Regards, Vicentiu

2 1

[Maria-developers] [GSoC'15] Running MaxScale and MariaDB servers on single machine
by sriram patil 09 Mar '15

09 Mar '15

Hi All, I tried running 2 MariaDB servers and MaxScale on my laptop. I gave different configurations to both MariaDB servers with separate data and log directories. Referred this <http://www.ducea.com/2009/01/19/running-multiple-instances-of-mysql-on-the-…> for it. Also have set up MaxScale from "MaxScale for rest of us" series on MariaDB blog. 1. https://mariadb.com/blog/maxscale-rest-us-part-1 2. https://mariadb.com/blog/maxscale-rest-us-part-2 3. https://mariadb.com/blog/maxscale-rest-us-part-3 4. https://mariadb.com/blog/maxscale-rest-us-part-4 So, i tried to set up the readwritesplit router with 1 master and 1 slave. Here, the replication mechanism worked fine but the queries are always executed on the master server. Example output for a read query: mysql -h localhost -u maxuser -p test -e "select c1, @@server_id from t1" Enter password: +------+-------------+ | c1 | @@server_id | +------+-------------+ | 1 | 1 | +------+-------------+ server_id for master is 1 whereas for slave it is 11, which is never displayed in the output. Can someone help me with this? Should I try the same config with one more slave? Are there any better resources for setting up MaxScale? Thanks, Sriram

2 5

[Maria-developers] MariaDB Maxscale Project (GSOC 2015)
by Aalekh Nigam 09 Mar '15

09 Mar '15

Hello, I am Aalekh Nigam, 3rd year Undergraduate Student at JIIT, Noida. I have recently successfully completed Mozilla Winter Of Security and Owasp Winter of Code, and is aiming for MaxScale projects for this GSOC. Can someone please guide me through starter’s bug for Maxscale to get my hands on with MaxScale development ? Thank You —Aalekh

2 1

[Maria-developers] MDEV-7643 review
by Elena Stepanova 09 Mar '15

09 Mar '15

Hi Sergei, http://lists.askmonty.org/pipermail/commits/2015-March/007508.html Could you please check patch for https://mariadb.atlassian.net/browse/MDEV-7643 (MTR creates nested links when tests are run with --mem)? It's in the area that you looked at recently, so you might think of something that I could have missed. Thanks, Elena

2 1

Re: [Maria-developers] [Commits] e464bc6: MDEV-7107 Sporadic test failure in multi_source.multisource
by Kristian Nielsen 09 Mar '15

09 Mar '15

elenst(a)montyprogram.com writes: > revision-id: e464bc6fe3d7566831da5e26447d90e758b5aa2a > committer: Elena Stepanova > timestamp: 2015-03-09 02:07:47 +0200 > message: > > MDEV-7107 Sporadic test failure in multi_source.multisource > > Extend show_slave_status.inc to run SHOW ALL SLAVES STATUS and > SHOW SLAVE 'name' STATUS on demand, and make the test use > the include file instead of direct SHOW statements Looks fine, thanks! Ok to push. I agree with your changes to show_slave_status.inc. I think they will be useful for futute test cases also. - Kristian.

1 0

[Maria-developers] MDEV-7107 review
by Elena Stepanova 09 Mar '15

09 Mar '15

Hi Kristian, Could you please take a quick look at the patch for MDEV-7107 (Sporadic test failure in multi_source.multisource). http://lists.askmonty.org/pipermail/commits/2015-March/007543.html I don't expect you'll mind changes to the test itself, we discussed earlier that's how SHOW SLAVE STATUS should be handled; but please check if you're okay with the additions to show_slave_status.inc, or you would prefer a separate include file for SHOW ALL SLAVES STATUS instead. Thanks, Elena

1 0

[Maria-developers] rpl test with gtid as default
by Jonas Oreland 09 Mar '15

09 Mar '15

what do you think ? /Jonas

3 3

Re: [Maria-developers] a1c4620: MDEV-6858: enforce_storage_engine option
by Sergei Golubchik 09 Mar '15

09 Mar '15

Hi, Jan! On Mar 08, Jan Lindström wrote: > revision-id: a1c4620646d43eaff979c132a57ee2101070fa5e > parent(s): 1b74f32b1d94465f6d6e14e4aa7ba1f94c32e39e > committer: Jan Lindström > branch nick: 10.1-innodb > timestamp: 2015-03-08 17:23:05 +0200 > message: > > MDEV-6858: enforce_storage_engine option > > Merge from Percona Server enforced use of a specific storage engine > authored by Stewart Smith. > > Modified to be session variable and modifiable only by SUPER. Use > similar implementation as default_storage_engine. > > diff --git a/mysql-test/t/enforce_storage_engine.test b/mysql-test/t/enforce_storage_engine.test > new file mode 100644 > index 0000000..36231e6 > --- /dev/null > +++ b/mysql-test/t/enforce_storage_engine.test > @@ -0,0 +1,35 @@ ... > +--error ER_UNKNOWN_STORAGE_ENGINE > +CREATE TABLE t2 (c1 INT PRIMARY KEY AUTO_INCREMENT, c2 VARCHAR(10)) ENGINE=MyISAM; > + > +SET SESSION enforce_storage_engine=MyISAM; > +select @@session.enforce_storage_engine; > +select * from t1; > +drop table t1; > + > +--error 1286 > +SET SESSION enforce_storage_engine=FooBar; > + > +select @@session.enforce_storage_engine; Consider adding tests for "only modifiable by SUPER" (create a new user, connect with it, see that enforce_storage_engine cannot be changed), and for modified enforce_storage_engine (you tested that it can be changed, but didn't do any CREATE TABLE with the new value). > diff --git a/sql/handler.cc b/sql/handler.cc > index 12d7ffb..5d5ac30 100644 > --- a/sql/handler.cc > +++ b/sql/handler.cc > @@ -117,6 +117,15 @@ static plugin_ref ha_default_tmp_plugin(THD *thd) > return ha_default_plugin(thd); > } > > + > +static plugin_ref ha_enforced_plugin(THD *thd) > +{ > + if (thd->variables.enforced_table_plugin) > + return thd->variables.enforced_table_plugin; > + return NULL; > +} > + > + > /** @brief > Return the default storage engine handlerton for thread > > @@ -148,6 +157,25 @@ handlerton *ha_default_tmp_handlerton(THD *thd) > > > /** @brief > + Return the enforced storage engine handlerton for thread > + > + SYNOPSIS > + ha_enforce_handlerton(thd) > + thd current thread > + > + RETURN > + pointer to handlerton OR NULL > + > +*/ > +handlerton *ha_enforced_handlerton(THD *thd) > +{ > + plugin_ref plugin= ha_enforced_plugin(thd); > + if (plugin) > + return plugin_hton(plugin); > + return NULL; > +} > + > +/** @brief > Return the storage engine handlerton for the supplied name > > SYNOPSIS > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index b97742d..6966fd9 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -4738,8 +4738,8 @@ static void add_file_to_crash_report(char *file) > #define init_default_storage_engine(X,Y) \ > init_default_storage_engine_impl(#X, X, &global_system_variables.Y) > > -static int init_default_storage_engine_impl(const char *opt_name, > - char *engine_name, plugin_ref *res) > +int init_default_storage_engine_impl(const char *opt_name, > + char *engine_name, plugin_ref *res) You've made init_default_storage_engine_impl() extern, but you never use it anywhere. And you've forgot to create a command line option for enforced_table_plugin. > { > if (!engine_name) > { > diff --git a/sql/sql_table.cc b/sql/sql_table.cc > index e9a1ae9..184c073 100644 > --- a/sql/sql_table.cc > +++ b/sql/sql_table.cc > @@ -9745,12 +9745,24 @@ static bool check_engine(THD *thd, const char *db_name, > DBUG_ENTER("check_engine"); > handlerton **new_engine= &create_info->db_type; > handlerton *req_engine= *new_engine; > + handlerton *enf_engine= ha_enforced_handlerton(thd); I'd write it directly as thd->variables.enforced_table_plugin ? plugin_hton(thd->variables.enforced_table_plugin) : NULL; Or as an inlined function here, in sql_table.cc. Not as two small but non-inlined functions in handler.cc, that are only used once here. > bool no_substitution= thd->variables.sql_mode & MODE_NO_ENGINE_SUBSTITUTION; > *new_engine= ha_checktype(thd, req_engine, no_substitution); > DBUG_ASSERT(*new_engine); > if (!*new_engine) > DBUG_RETURN(true); > > + if (enf_engine) > + { > + if (enf_engine != *new_engine && no_substitution) > + { > + const char *engine_name= ha_resolve_storage_engine_name(req_engine); > + my_error(ER_UNKNOWN_STORAGE_ENGINE, MYF(0), engine_name, engine_name); > + DBUG_RETURN(TRUE); > + } > + *new_engine= enf_engine; > + } > + > if (req_engine && req_engine != *new_engine) > { > push_warning_printf(thd, Sql_condition::WARN_LEVEL_NOTE, > diff --git a/sql/sys_vars.cc b/sql/sys_vars.cc > index 8371df0..cd53714 100644 > --- a/sql/sys_vars.cc > +++ b/sql/sys_vars.cc > @@ -3437,6 +3437,28 @@ static Sys_var_plugin Sys_default_tmp_storage_engine( > SESSION_VAR(tmp_table_plugin), NO_CMD_LINE, > MYSQL_STORAGE_ENGINE_PLUGIN, DEFAULT(&default_tmp_storage_engine)); > > +extern int init_default_storage_engine_impl(const char* opt_name, char *engine_name, plugin_ref *plugin); Not used below. > + > + > +static bool check_super_and_not_null(sys_var *self, THD*thd, set_var *var) I think that NULL value should be allowed, it means "don't enforce a storage engine". > +{ > +#ifndef NO_EMBEDDED_ACCESS_CHECKS > + if (!(thd->security_ctx->master_access & SUPER_ACL)) > + { > + my_error(ER_SPECIFIC_ACCESS_DENIED_ERROR, MYF(0), "SUPER"); > + return true; > + } > +#endif > + return var->value && var->value->is_null(); > +} > + > +static Sys_var_plugin Sys_enforce_storage_engine( > + "enforce_storage_engine", "Force the use of a storage engine for new " > + "tables", > + SESSION_VAR(enforced_table_plugin), > + NO_CMD_LINE, MYSQL_STORAGE_ENGINE_PLUGIN, > + DEFAULT(0), NO_MUTEX_GUARD, NOT_IN_BINLOG, ON_CHECK(check_super_and_not_null)); > + > #if defined(ENABLED_DEBUG_SYNC) > /* > Variable can be set for the session only. Regards, Sergei

1 0

[Maria-developers] [GSoC'15] MaxScale Project
by sriram patil 07 Mar '15

07 Mar '15

Hi Markus, I am Sriram, a Masters' student at IIIT Hyderabad, India. I have worked with MariaDB in GSoC-2014 on MDEV-5359 under Alexander Barkov. I have also documented my work on my blog <http://srirampatil.tumblr.com/>. I am interested to work on "MaxScale filter to capture incoming operations for consumption in external sources". I have downloaded and built MariaDB 10.1 source code from github. I was trying to build MaxScale but it resulted in some errors. I followed the installation instructions given on MaxScale github(develop branch). The error is as follows /home/sriram/gsoc/MaxScale/query_classifier/query_classifier.cc: In function ‘bool skygw_stmt_causes_implicit_commit(LEX*, int*)’: /home/sriram/gsoc/MaxScale/query_classifier/query_classifier.cc:848:40: error: ‘struct LEX’ has no member named ‘drop_temporary’ succp = !(lex->drop_temporary); ^ make[2]: *** [query_classifier/CMakeFiles/query_classifier.dir/query_classifier.cc.o] Error 1 make[1]: *** [query_classifier/CMakeFiles/query_classifier.dir/all] Error 2 I checked struct LEX from MariaDB source code and it does not have the mentioned field. So, is MaxScale expecting some other MariaDB source code? It would be great if you could give me some pointers regarding the same. Thanks, Sriram Patil

2 2

Re: [Maria-developers] GSoC 15 : MaxScale Project under Markus Makela
by Markus Mäkelä 06 Mar '15

06 Mar '15

Hi, The most up to date documentation for MaxScale can be found on the develop branch on GitHub: https://github.com/mariadb-corporation/MaxScale/blob/develop/Documentation/… I suggest using that rather than the PDF documentation since it's a lot more easy to use. The filter interface can be found in the server/include/filter.h file. All filters must implement these functions for them to work with MaxScale. The filters are located in the server/modules/filter folder. The best way to get a hang of the filters is to take a look at one and the regexfilter and qlafilter are the ones that show the filter interface in action without having much code in them. Other useful stuff to look at can be found in the server/include folder are buffer.h(MaxScale uses these to route queries though it), modutils.h(useful functions for SQL handling), housekeeper.h(for tasks that take a long time this can be used) and hashtable.h(a generic hashtable). All of the MaxScale team works around UTC+1. For quick questions ask them on #maxscale on Freenode but email will most likely be answered as fast as IRC. Markus > Hello guys, > > As per the official list > <https://mariadb.com/kb/en/mariadb/google-summer-of-code-2015/> of projects > by MariaDB, I'm interested in the project - MaxScale filter to capture > incoming operations for consumption in external sources ( Mentor : Markus > Makela ) > > *I've 3 requests/doubts : * > > 0.I've downloaded the MaxScale code from github > <https://github.com/mariadb-corporation/MaxScale> and have read the > documentation. > It says the filter configuration file is : MaxScale.ini > I didn't find this file in the codebase. > > Nor was I able to figure out the code-location related to the "filter" > module. > > 1.Kindly suggest for the further things I should do/try. > > Shall I install MariaDB & MaxScale? > What part of code-base should I look into & play around? > > 2.What is the UTC time when most of you guys are online on IRC-channel > (#maria)? > > Since I'm from India, I need to know the time when most of you guys are > online to get immediate help on IRC. > > > Thanks in advance. > > -- > Lokesh Walase -- Markus Mäkelä, Software Engineer MariaDB Corporation t: +358 40 7740484 | Skype: markus.j.makela

1 0

[Maria-developers] Comments/thoughts on patch
by Jonas Oreland 06 Mar '15

06 Mar '15

Hi Kristian, I wrote attached patch (so that i would understand what code actually does) and found myself while refactoring also doing a change, namely that i removed the check for server_id in a couple of places. it still passes all tests... could you comment on this, or write(outline) a testcase that fails with my patch. i think functionality that i might have removed would be if you write have 2 mysqld M1 & M2 and your replicate both way...and you *don't* use domain_id...and you write concurrently on both mysqld (but maybe disjoint data ??). feedback/comments appreciated. /Jonas ps. patch applies to f4f37533a09b9776e8d5ac3f3a27957f553c9043

2 9