April 2015 - developers - lists.mariadb.org

[Maria-developers] PLEASE REVIEW: (MDEV-7574) Security definer views don't work with CONNECT ODBC tables
by Alexander Barkov 26 Jul '15

26 Jul '15

Hello Sergei, Please review a patch that fixes the problem described in MDEV-7574. The idea is that a SELECT from a view over a CONNECT table now checks FILE privileges of the view definer (unless CREATE VIEW states SQL SECURITY INVOKER). It looks like a very good idea and gives more possible security options. The administrator can create a VIEW and give access to it to some user, without giving FILE privilege to this user. I'm not really sure about the patch, but it seems to do the trick :) From what I understood, FILE_ACL is written (among the other privileges) into thd->security_ctx.privilege in TABLE_LIST::prepare_security(). In case of a DEFINER view, thd->security_ctx.privilege is filled exactly with the definer privileges, and to the invoker privileges otherwise. So inside ha_connect::check_privileges() the fact that there is FILE_ACL in thd->security_ctx.privilege means that TABLE_LIST::prepare_security() was previously called and FILE_ACL is set to DEFINER or INVOKER, according to the view definition. This is exactly what we need. I'm not sure about the opposite: if there is no FILE_ACL in thd->security_ctx.privilege, what does it mean? Does it mean that there is no FILE_ACL for the effective user? Or can it also mean that TABLE_LIST::prepare_security() was not called? Thanks. On 02/12/2015 04:04 AM, Olivier Bertrand wrote: > Hi Alexander, > > Can you take care of this issue? I know you wrote the > ha_connect::check_privileges function and I personnally have not the > faintest idea about how this must be checked. > > Thanks, > Olivier > > > -------- Message transféré -------- > Sujet : [JIRA] (MDEV-7574) Security definer views don't work with > CONNECT ODBC tables > Date : Wed, 11 Feb 2015 23:21:00 +0200 (EET) > De : Elena Stepanova (JIRA) <jira(a)mariadb.atlassian.net> > Pour : bertrandop(a)gmail.com > > > > [https://mariadb.atlassian.net/browse/MDEV-7574?page=com.atlassian.jira.plug… ] > > Elena Stepanova reassigned MDEV-7574: > ------------------------------------- > > Assignee: Olivier Bertrand > Fix Version/s: 10.0 > >> Security definer views don't work with CONNECT ODBC tables >> ---------------------------------------------------------- >> >> Key: MDEV-7574 >> URL:https://mariadb.atlassian.net/browse/MDEV-7574 >> Project: MariaDB Server >> Issue Type: Bug >> Components: Storage Engine - Connect >> Affects Versions: 10.0.16 >> Reporter: Geoff Montee >> Assignee: Olivier Bertrand >> Labels: connect-engine >> Fix For: 10.0 >> >> >> One possible way to get around the requirement for having the FILE privilege to access ODBC tables with CONNECT would be to have them called indirectly via a security definer view. However, it does not currently work. >> Create a security definer view to access the ODBC table, then create a new user: >> {code} >> [gmontee@localhost ~]$ mysql -u root tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 16 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SHOW CREATE TABLE datetime_table; >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> | Table | Create Table | >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> | datetime_table | CREATE TABLE `datetime_table` ( >> `id` int(10) NOT NULL, >> `modifiedon` datetime DEFAULT NULL >> ) ENGINE=CONNECT DEFAULT CHARSET=latin1 CONNECTION='DSN=connect_test_azure;UID=connect_test;PWD=Password1' `TABLE_TYPE`='ODBC' `TABNAME`='dbo.datetime_table' | >> +----------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ >> 1 row in set (0.00 sec) >> MariaDB [tmp]> DROP USER 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> CREATE OR REPLACE >> -> DEFINER = CURRENT_USER >> -> SQL SECURITY DEFINER >> -> VIEW datetime_view >> -> AS SELECT * FROM datetime_table; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> CREATE USER 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> GRANT SELECT ON datetime_view TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> \q >> Bye >> {code} >> Now connect with the new user, and try to use the view: >> {code} >> [gmontee@localhost ~]$ mysql -u connecttest tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 17 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SELECT * FROM datetime_view; >> ERROR 1045 (28000): Access denied for user 'connecttest'@'localhost' (using password: NO) >> MariaDB [tmp]> \q >> Bye >> {code} >> It didn't work, so give the user privileges on the underlying ODBC table: >> {code} >> [gmontee@localhost ~]$ mysql -u root tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 18 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> GRANT FILE ON *.* TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> GRANT SELECT ON datetime_table TO 'connecttest'@'localhost'; >> Query OK, 0 rows affected (0.00 sec) >> MariaDB [tmp]> \q >> Bye >> {code} >> Now try using the view again: >> {code} >> [gmontee@localhost ~]$ mysql -u connecttest tmp >> Reading table information for completion of table and column names >> You can turn off this feature to get a quicker startup with -A >> Welcome to the MariaDB monitor. Commands end with ; or \g. >> Your MariaDB connection id is 19 >> Server version: 10.0.15-MariaDB-log MariaDB Server >> Copyright (c) 2000, 2014, Oracle, SkySQL Ab and others. >> Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. >> MariaDB [tmp]> SELECT * FROM datetime_view; >> +----+---------------------+ >> | id | modifiedon | >> +----+---------------------+ >> | 1 | 2014-01-01 00:00:00 | >> | 2 | 2016-01-01 00:00:00 | >> +----+---------------------+ >> 2 rows in set (0.24 sec) >> {code} > > > > -- > This message was sent by Atlassian JIRA > (v6.4-OD-14-082#64012) > > >

2 9

[Maria-developers] Please review: MDEV-7824 [Bug #68041] Zero date can be inserted in strict no-zero mode through a default value
by Alexander Barkov 25 Jun '15

25 Jun '15

Hi Sergei, Please review a patch for mdev-7824. It's based on a MySQL patch for http://bugs.mysql.com/bug.php?id=68041 and is a blocker for: MDEV-3929 Add full support for auto-initialized/updated timestamp and datetime Thanks.

2 9

[Maria-developers] MDEV-6877 - binlog_row_image implementation advice
by Vicențiu Ciorbaru 25 Jun '15

25 Jun '15

Hi Sergei! This past week I've done quite a bit of reading regarding the replication code and how the binlog is used by both mysqlbinlog and the slaves in order to do replication. I think I now have a good enough understanding of the flow of the code for both MySQL and MariaDB to actually start coding the feature into MariaDB. I do have a couple of unknowns still. I don't quite understand what's the use for the TABLE_MAP event. My intuition tells me its some sort of id we assign to a table name (test.t1 for example) that gets used afterwards in the binlog row events. We seem to be using a bitmap of columns that we want to log into the binlog. MySQL does extend the TABLE class to flip the bits according to the binlog_row_image variable. That seems like the first place to start with the addition. I could not find any other "hidden" logic that we use to choose how we log row operations in the binlog. What I would like to know is if there are any other pitfalls that I am supposed to watch out for, or if there is anything else I may be missing regarding the logging part. When it comes to actually doing the replication, I concluded that Log_event::do_apply_event is the place where we begin translating the event from the binlog to an SQL statement. Another concern that I have is how to test the implementation. Right now, I run the test, get the binlog file and print it with mysqlbinlog and see if the output is what I expect. Do we have something within mysql-test-run that automates this? Regards, Vicentiu

2 7

[Maria-developers] Memory barrier problem in InnoDB/XtraDB mutex implementation causing hangs
by Kristian Nielsen 27 May '15

27 May '15

I have been debugging some test failures seen in Buildbot: https://mariadb.atlassian.net/browse/MDEV-7026 After some debugging, this is what I think is going on. I will refer to MariaDB 5.5 sources, though the problem is also in 10.0. InnoDB/XtraDB mutexes are taken in mutex_enter_func() and unlocked in mutex_exit_func(). Simplifying for clarity, here are the relevant parts of the logic: ENTER: # First spin wait, hoping to get the mutex without yielding. os_compare_and_swap_ulint(&mutex->waiters, 0, 1); if (os_atomic_test_and_set_byte(&mutex->lock_word, 1)) sync_array_wait_event() RELEASE: os_atomic_lock_release_byte(&mutex->lock_word); os_rmb; waiters = *(volatile *)&mutex->waiters; if (waiters) mutex_signal_object(mutex); The interesting point here is how to ensure that we do not lose the wakeup of a waiting thread when the holding thread releases the mutex. The idea is that the waiting thread first sets mutex->waiters=1. Then it checks if the mutex is free - if not, it goes to sleep. The thread that releases the lock first marks the mutex free. Then it checks if there are any waiters, and if so wakes them up. For this to work, we need to ensure that the setting of waiters=1 has completed before the load of lock_word can start - a full memory barrier. Likewise, we need the setting of lock_word to 0 to complete before the load of mutex->waiters - again a full memory barrier. Otherwise we can get something like this: ENTER RELEASE Start store to mutex->waiters Start store to lock_word Load mutex->lock_word Store to lock_word becomes visible Load mutex->waiters Store to waiters becomes visible Check lock word==1 Check waiters==0, skip wakeup Sleep (forever) Or this: ENTER RELEASE Start store to lock_word Start store to mutex->waiters Load mutex->waiters Store to waiters becomes visible Load mutex->lock_word Store to lock_word becomes visible Check lock word==1 Sleep (forever) Check waiters==0, skip wakeup (So both full barriers are needed, the one in ENTER to prevent the first example, the one in RELEASE to prevent the second). It looks like for x86, the full barriers were broken in MariaDB 5.5.40 and 10.0.13. os_compare_and_swap_ulint() is defined as either __sync_bool_compare_and_swap() or atomic_cas_ulong(), both of which implies a full barrier. So ENTER looks ok. os_atomic_lock_release_byte() however is now defined as __sync_lock_release(). This is _not_ a full barrier, just a release barrier. So the RELEASE case seems to be incorrect, allowing the second deadlock example to occur. Previously, RELEASE used os_atomic_test_and_set_byte(), which is __sync_lock_test_and_set(). This is defined in GCC docs as an "aquire" barrier only, which is also wrong, obviously. But it happens to generate an XCHG instruction on x86, which is a full barrier. This is probably why it works on x86 (and probably why it did not work on PowerPC). Here is a small test program, and the assembly from GCC 5.7 on amd64: void test(unsigned *p, unsigned *q) { while (__sync_lock_test_and_set(q, 1)) { } *p++; __sync_lock_release(q); } test: movl $1, %edx .L2: movl %edx, %eax xchgl (%rsi), %eax testl %eax, %eax jne .L2 movl $0, (%rsi) ret As can be seen, the __sync_lock_test_and_set() generates a full barrier, but the __sync_lock_release() generates nothing (as this is sufficient for release semantics for the rather strong memory order on x86). So the InnoDB mutexes look completely broken from MariaDB 5.5.40 and 10.0.13 :-( This is consistent with the observations in MDEV-7026. A thread is waiting for wakeup on a mutex that is already marked free. Apparently this is not a new problem. This comment in mutex_exit_func() makes me want to cry: /* A problem: we assume that mutex_reset_lock word is a memory barrier, that is when we read the waiters field next, the read must be serialized in memory after the reset. A speculative processor might perform the read first, which could leave a waiting thread hanging indefinitely. Our current solution call every second sync_arr_wake_threads_if_sema_free() to wake up possible hanging threads if they are missed in mutex_signal_object. */ So someone found the mutex implementation broken, but instead of fixing it, they implemented a horrible workaround to try and break any deadlocks that might occur. (The reason that the deadlocks are not broken in the MDEV-7026 seems to be that it occurs during startup, before starting the srv_error_monitor_thread() that does the sync_arr_wake_threads_if_sema_free()). Now, what is also interesting is that this seems to explain very nicely the many server lockups we have seen for users that upgrade to recent MariaDB versions. I was doing a very detailed investigation of one such case where the user was able to supply unusually detailed information. I found a thread that was stuck waiting on a mutex, but no other threads seemed to be holding that mutex. This is exactly what would be seen in case of a lost wakeup due to this issue. Furthermore, the sync_arr_wake_threads_if_sema_free() mechanism, as well as the normal InnoDB "long semaphore wait", was itself blocked on that same mutex wait, which explains why they were not effective for the user in that particular case. So it looks like we need to revert the incorrect patch and release new 5.5.40a and 10.0.15 releases ASAP, to solve these hangs for users. And do a proper patch for PowerPC with proper full memory barriers. (Incidentally, the os_rmb in RELEASE seems to also be part of some PowerPC patch, it also looks completely wrong). However, more importantly, this issue clearly shows some fundamental problems in our development procedures that we need to fix ASAP. Just look at it. We have users (and customers!) that suffer from strange hangs. This is their production systems that are down. Support and developers are unable to help them due to the difficulty of debugging rare race conditions in production systems. And all the time the bug was staring us in the face, easily reproducable in our own Buildbot! But we deliberately chose to ignore those failures. The only thing that matters is "when can you push", and getting more releases out. Never mind what kind of crap is then pushed out to users. I am deeply ashamed of treating our users like this. And extremely unhappy. I even wrote about this (the importance of not ignoring Buildbot failures) just a few weeks ago. This was completely ignored, I got zero replies, and the weekly calls continued with mindless juggling of Jira numbers and buggy releases. As a result, our users suffer. We need to stop this. Please? - Kristian.

4 16

[Maria-developers] MDEV-7807 information_schema.processlist truncates queries with binary strings
by Alexander Barkov 07 May '15

07 May '15

Hi Sergei, Please review the patch for: MDEV-7807 information_schema.processlist truncates queries with binary strings The patch is for 10.1, as agreed with the reporter. Previously in 10.1 we fixed binary->string conversion behaviour not to truncate on bad bytes, and replace bad bytes to question marks instead. That fixed half of the problem reported. This patch adds a new new column "PROCESSLIST.INFO_BINARY blob". Thanks.

2 1

[Maria-developers] Please review: MDEV-7778 impossible create copy of table, if table contain default value for timestamp field
by Alexander Barkov 04 May '15

04 May '15

Hi Sergei, Please review a patch for MDEV-7778. As agreed on IRC, this is a merge from the latest MySQL, which has already fixed the problem. Greetings.

2 1

[Maria-developers] [GSoC 2015] Accepted Student- Self Introduction
by Delveri chick 30 Apr '15

30 Apr '15

Hello everyone ! I am Delveri Chick, a junior software engineering student from Cameroon. I have been accepted into GSoC 2015 to hack on project titled : Improved Temporary Tables. Here <http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/…> is my GSoC proposal. Sergei Golubchik will be mentoring me for this project. I am really excited to spend my summer hacking on MariaDB, and hoping to learn a lot of things from the developer community. Thanks. Delveri

2 1

Re: [Maria-developers] [Commits] 13ecde8: Fix compiler warnings.
by Vicențiu Ciorbaru 30 Apr '15

30 Apr '15

Hi Jan! I have one concern with this patch. See below: On Thu, 30 Apr 2015 at 11:45 Jan Lindström <jan.lindstrom(a)mariadb.com> wrote: > revision-id: 13ecde851f08a7952f774707b19734f351bb6598 > parent(s): 5027e0b035f96e2583eff2d1ac71c7c44a093ac8 > committer: Jan Lindström > branch nick: 10.0-git > timestamp: 2015-04-30 11:44:34 +0300 > message: > > Fix compiler warnings. > > --- > storage/innobase/sync/sync0sync.cc | 27 +++++++++++++-------------- > storage/xtradb/sync/sync0sync.cc | 27 +++++++++++++-------------- > 2 files changed, 26 insertions(+), 28 deletions(-) > > diff --git a/storage/innobase/sync/sync0sync.cc > b/storage/innobase/sync/sync0sync.cc > index 121f8e9..78d86f3 100644 > --- a/storage/innobase/sync/sync0sync.cc > +++ b/storage/innobase/sync/sync0sync.cc > @@ -862,10 +862,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > I think this here has to be arr->at(i), or &(*arr)[i]. Doing &arr[i] will actually get the i'th std::vector<> which does not exist, since arr is a pointer to only one std::vector<>. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -897,10 +897,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -944,10 +944,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -993,10 +993,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1053,10 +1053,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1331,7 +1331,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1377,14 +1377,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > - for (std::vector<sync_level_t>::iterator it = array->elems.begin(); > it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1471,7 +1471,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } > diff --git a/storage/xtradb/sync/sync0sync.cc > b/storage/xtradb/sync/sync0sync.cc > index d0e3b71..9dcdd9c 100644 > --- a/storage/xtradb/sync/sync0sync.cc > +++ b/storage/xtradb/sync/sync0sync.cc > @@ -970,10 +970,10 @@ sync_thread_levels_g( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level <= limit) { > if (warn) { > @@ -1005,10 +1005,10 @@ sync_thread_levels_contain( > { > ulint i; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > const sync_level_t* slot; > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1052,10 +1052,10 @@ sync_thread_levels_contains( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; i++) { > + for (i = 0; i < arr->size(); i++) { > sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (sync_level_t*)&arr[i]; > > if (slot->latch != NULL && slot->level == level) { > > @@ -1101,10 +1101,10 @@ sync_thread_levels_nonempty_gen( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!dict_mutex_allowed > @@ -1161,10 +1161,10 @@ sync_thread_levels_nonempty_trx( > > arr = thread_slot->levels; > > - for (i = 0; i < arr->n_elems; ++i) { > + for (i = 0; i < arr->size(); ++i) { > const sync_level_t* slot; > > Same here. > - slot = &arr->elems[i]; > + slot = (const sync_level_t*)&arr[i]; > > if (slot->latch != NULL > && (!has_search_latch > @@ -1456,7 +1456,7 @@ sync_thread_add_level( > > sync_level.latch = latch; > sync_level.level = level; > - array->elems.push_back(sync_level); > + array->push_back(sync_level); > > mutex_exit(&sync_thread_mutex); > } > @@ -1502,14 +1502,14 @@ sync_thread_reset_level( > > array = thread_slot->levels; > > - for (std::vector<sync_level_t>::iterator it = > array->elems.begin(); it != array->elems.end(); ++it) { > + for (std::vector<sync_level_t>::iterator it = array->begin(); it > != array->end(); ++it) { > sync_level_t level = *it; > > if (level.latch != latch) { > continue; > } > > - array->elems.erase(it); > + array->erase(it); > mutex_exit(&sync_thread_mutex); > return(TRUE); > } > @@ -1597,7 +1597,6 @@ sync_thread_level_arrays_free(void) > > /* If this slot was allocated then free the slot memory > too. */ > if (slot->levels != NULL) { > - > slot->levels->elems.erase(slot->levels->elems.begin(),slot->levels->elems.end()); > delete slot->levels; > } > } >

1 0

Re: [Maria-developers] [Commits] 8a18bbc: MDEV-8079: Crash when running MariaDB Debug with InnoDB on Windows
by Vicențiu Ciorbaru 30 Apr '15

30 Apr '15

Here is a patch that fixes all compilation related issues. Unfortunately it's based on 10.1. It might need a bit of tweaking to merge directly into 10.0

1 0

[Maria-developers] GSoC 2015 student
by Blessing Atie 30 Apr '15

30 Apr '15

Hello everyone, My surname is Blessing and I am a student at University of Buea. I am very happy to be selected by MariaDb to part take in GSoC 2015. I will be working on Improving table Functions mentored Sergei Golubchik and I look forward to know him soon on #maria as well as the other students. I equally look forward on using this as an opportunity to learn more about open source and MariaDB community. Can't wait to get hands dirty on MariaDB source. Thanks. Blessing

2 1

Re: [Maria-developers] MDEV-7774: Crash when dropping user within rebuild_role_grants
by Sergei Golubchik 29 Apr '15

29 Apr '15

Hi, Vicentiu! On Mar 13, vicentiu(a)mariadb.org wrote: > revision-id: 22884d35e39ba078dddf5c15b42dd7e2ebb39c07 > parent(s): 184f718fef0101a7559364cb97e22ee568e64c12 > committer: Vicențiu Ciorbaru > branch nick: server > timestamp: 2015-03-13 20:12:22 +0200 > message: > > MDEV-7774: Crash when dropping user within rebuild_role_grants > > The issue comes from not taking all possibilities to match an entry > within the roles_mapping HASH, when updating the data structure. ok to push Regards, Sergei

1 0

[Maria-developers] Likely a dead code in build_equal_items_for_cond()
by Alexander Barkov 29 Apr '15

29 Apr '15

Hi Sanja and Igor, Can you please help to understand this pieces of code in sql_select.cc in 10.0: > else if (cond->type() == Item::FUNC_ITEM || > cond->real_item()->type() == Item::FIELD_ITEM) > { It seems that the "cond->real_item()->type() == Item::FIELD_ITEM" part of this condition is a dead code. I added a DBUG_ASSERT in the very beginning of this block, like this: > else if (cond->type() == Item::FUNC_ITEM || > cond->real_item()->type() == Item::FIELD_ITEM) > { > DBUG_ASSERT(cond->real_item()->type() != Item::FIELD_ITEM); and run all tests. Nothing crashed. I suspect that the following scenario could happen: 1. In April 2011 Igor fixed bugs #717577, #724942 with this commit: > commit 8d9dd21d85e257051b45b2f779dcd9bf696bf9e1 > Author: Igor Babaev <igor(a)askmonty.org> Wed Apr 27 06:58:41 2011 > Committer: Igor Babaev <igor(a)askmonty.org> Wed Apr 27 06:58:41 2011 > > Fixed LP bugs #717577, #724942. and this line was probably to handle conditions like "WHERE field". 2. In July 2011 Sanja introduced a new function normalize_cond(), with this commit: > commit 20a2e1d0ac46e375ee7246576b541624c6f8f028 > Author: unknown <sanja(a)askmonty.org> Thu Jul 21 11:20:55 2011 > unknown <sanja(a)askmonty.org> Thu Jul 21 11:20:55 2011 so all conditions "WHERE/HAVING field" are now replaced to "WHERE/HAVING field<>0". So now, by the time of a build_equal_items_for_cond() call all conditions are already replaced and no FIELD_ITEM are actually possible. Can you please confirm this? If my guess is correct then this part can now be safely removed: > || > cond->real_item()->type() == Item::FIELD_ITEM Thanks.

1 0

[Maria-developers] MDEV-7802 adding status variables - backport to 10.0 request
by Daniel Black 29 Apr '15

29 Apr '15

Hi, I'm requesting a backport of MDEV-7802 https://github.com/MariaDB/server/pull/30/files to 10.0 It added status variables which where important to determining what operational values to set binlog_commit_wait_usec / binlog_commit_wait_count variables to. With parallel replication efficiency and general group commit IO reduction dependent on the tradeoff of these settings with the commit delay, the status variables binlog_group_commit_trigger_count, binlog_group_commit_trigger_timeout and binlog_group_commit_trigger_lock_wait that this patch adds are operationally important. The changes added a few variables and didn't affect the flow of the program at all. In the binary log execution path, no locks where added and only a few increments of static variables where added. There was an additional lock usage of LOCK_prepare_ordered in the show global status for the period to copy the added variables into the global status structures. I'm quite aware of the dangers of show global status holding locks wrongly (MDEV-7126) I don't suspect this does. On the balance of risk/benefit can I request that this feature be merged to 10.0. -- -- Daniel Black, Engineer @ Open Query (http://openquery.com.au) Remote expertise & maintenance for MySQL/MariaDB server environments.

4 4

[Maria-developers] GSoC 2015 Accepted Student
by arlene seuleu 28 Apr '15

28 Apr '15

Hi everyone, I am Arlene Flavie a computer engineering student at the university of Buea and I just got confirmation mail that I was selected to participate in the Google summer of code 2015 under MariaDB. I wish to use this opportunity to thank the mentors for giving me this opportunity to contribute to opensource. I wish to learn much in this experience as I will be Mentored by Sanda Byelkin on the project Import and Export data formats into and from dynamic columns. I look forward to do a similar introduction of myself on #maria. Thanks Arlene

1 0

[Maria-developers] MDEV-7950 Item_func::type() takes 0.26% in OLTP RO
by Alexander Barkov 28 Apr '15

28 Apr '15

Hi Sergey, Can you please review the "step 2" part of MDEV-7950? This is rather a mechanical cut-and-paste change. It does the following things: 1. Removes the function build_equal_items_for_cond() and introduces a new method Item::build_equal_items() instead, with specific implementations in the following Items: Item (the default implementation) Item_ident_or_func_or_sum Item_cond Item_cond_and 2. Adds a new abstract class Item_ident_or_func_or_sum, a common parent for Item_ident and Item_func_or_sum, as they have exactly the same build_equal_items(). 3. Renames Item_cond_and::cond_equal to Item_cond_and::m_cond_equal, to avoid confusion between the member and local variables named "cond_equal". The main purpose of this patch is to prepare to the next step in MDEV-7950. But it already improves performance per se: it gets rid of some virtual calls: - The former call for "((Item_cond*) cond)->functype()" is not needed any more, because Item_cond and Item_cond_and now have different implementations of the method build_equal_items(). - This condition: "else if (cond->type() == Item::FUNC_ITEM || cond->real_item()->type() == Item::FIELD_ITEM)" (which used to cover Item_func, Item_ident and Item_ref) consisted of three virtual calls. It's now replaced by a single virtual call for Item_ident_or_func_or_sum::build_equal_items(), which covers all three item types. Thanks.

2 2

[Maria-developers] Mariadb java client issue.
by 김경남 28 Apr '15

28 Apr '15

Hi, I hava a issue of using mariadb java client. I can't get column alias from query result set. My query as below. select col1 as column_alias1 from table1; reuslt: --------------------- col1 ------------------------ xxx ... In case of mysql connectorJ, there was a same issue. so I added a option like "useOldAliasMetadataBehavior=true" to connection string and that issue solved. but I cant't solve this issue in case of using mariadb java client. Is there a correct way? Regards, Kyungnam kim 김경남 부책임연구원 솔루션사업본부 정보기술 연구원 신기술개발팀 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.

1 0

[Maria-developers] MariaDB / Galera BUG
by Andrew W Elble 27 Apr '15

27 Apr '15

Environment: MariaDB-10.0.16 Galera-3-25.3.9 This statement does nasty things to a MariaDB+Galera cluster: CREATE TABLE u91rw_zoo_version (`version` varchar(255) NOT NULL) ENGINE=innoDB DEFAULT CHARSET=utf8 SELECT '3.3.3' as version; Statement fails to replicate to the other nodes because the target table doesn't exist. Cluster then disassembles itself. This patch makes the problem disappear. Please evaluate? (note: patch based against github.com/MariaDB/server.git) ============= diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index be57be9b223a..d0521ed896b8 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -3325,6 +3325,11 @@ mysql_execute_command(THD *thd) /* Store reference to table in case of LOCK TABLES */ create_info.table= create_table->table; + if (WSREP(thd) && (!thd->is_current_stmt_binlog_format_row() || + !create_info.tmp_table())) + { + WSREP_TO_ISOLATION_BEGIN(create_table->db, create_table->table_name, NULL) + } /* select_create is currently not re-execution friendly and needs to be created for every execution of a PS/SP. ============= We have a full environment setup in which to test. debug/trace available on request. Will open bug if required for your workflow. Thanks, Andy -- Andrew W. Elble aweits(a)discipline.rit.edu Infrastructure Engineer, Communications Technical Lead Rochester Institute of Technology PGP: BFAD 8461 4CCF DC95 DA2C B0EB 965B 082E 863E C912

2 6

[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 22 Apr '15

22 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 09 Apr '15

09 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 05 Apr '15

05 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