- developers - lists.mariadb.org

[Maria-developers] Problem in compiling Maria-db
by indiavaibhav vaibhavindia 02 Oct '15

02 Oct '15

Hello everyone, My name is Vaibhav.I am new to programming for open source. I am facing problems in trying to compile Maria-Db.As instructed on the website, I cloned the maria db source and installed all the files required for compilation. However on using cmake,I am getting an error,screenshot of which is attached is with this mail. Can someone please help me out? Thanks, Vaibhav Choudhary

2 3

Re: [Maria-developers] crosscompiling in buildroot: cannot find -laio and other link error
by Sylvain Raybaud 02 Oct '15

02 Oct '15

Ouch. I'm really sorry, I don't know what happend with my mua and why all these mails were sent to the list. Only the last one counts. Sincere apologies :'( On 02/10/15 17:10, Sylvain Raybaud wrote: > Hi Sergei! > > Thanks for your help. > > On 01/10/15 16:16, Sergei Golubchik wrote: >> Why would you build host variant for ha_connect.so with the library >> paths for the target architecture? > I don't actually, I don't know why this happened. > >> How do you invoke cmake? > The Buildroot system takes care of most of the maging. But... > >> Did you check >> https://mariadb.com/kb/en/mariadb/cross-compiling-mariadb/ ? Regards, >> Sergei > Ooops. For some reason I completely missed this page. Building only the > host variant of import_executables target eases cross-compilation a lot > indeed... Appart from that I had figured most of this out, or buildroot > was taking care of it. I still have a remark: I don't think I can > hardcode the value of > > HAVE_IB_GCC_ATOMIC_BUILTINS > > as suggested in https://lists.launchpad.net/maria-discuss/msg02911.html > because if I want this package accepted in buildroot it must > -- Sylvain Raybaud www.green-communications.fr

1 0

[Maria-developers] MariaDB Developer Meeting in Amsterdam Oct 13-15
by Rasmus Johansson 02 Oct '15

02 Oct '15

Hi maria-developers, There will be a MariaDB Developer Meeting taking place in Amsterdam on October 13-15. It would be great to see many of you there. The main focus of the event is as the title implies the development aspect of MariaDB, but also aspects like documentation, infrastructure and other community related topics will have their place in the event. Also MaxScale developers will be present. If you are interested please sign up by joining and rsvping the event's meetup page here: http://www.meetup.com/MariaDB-Developers/events/224068714/ The session backlog and the schedule for the three days are found here: https://docs.google.com/a/skysql.com/spreadsheets/d/17J_Jloc8I33nsEIE1KCZct… You'll notice that the schedule is not fixed and the idea is the following: - Everyone attending the meeting can affect the agenda by adding sessions to the session backlog - Everyone attending can/should vote on the session of interest in the backlog by raising the count in the Votes column Please feel free to suggest new sessions and remember to vote on the ones you think are most interesting (no limitation on how many you vote for). Best regards, Rasmus -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

2 2

Re: [Maria-developers] [Commits] 09eb231: MDEV-8762: file_key_management plugin should be disabled by default when linked statically
by Sergei Golubchik 01 Oct '15

01 Oct '15

Hi, Jan! That's not a good idea. It'd mean that installing a plugin is not enough, it must be explicitly enabled. I don't see any reason why one should be forced to do it. I'll comment in the bugreport. On Oct 01, Jan Lindström wrote: > revision-id: 09eb23148830c53e594cfb88dcb31f1b9e42ae5e (mariadb-10.1.7-33-g09eb231) > parent(s): 3a7cee05d6bac27c3c2f51afb8986c1581649bbc > committer: Jan Lindström > timestamp: 2015-10-01 14:27:10 +0300 > message: > > MDEV-8762: file_key_management plugin should be disabled by default when linked statically > > --- > sql/sql_plugin.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sql/sql_plugin.cc b/sql/sql_plugin.cc > index 6d8268e..1d2e2d8 100644 > --- a/sql/sql_plugin.cc > +++ b/sql/sql_plugin.cc > @@ -211,6 +211,7 @@ static struct > > /* we disable few other plugins by default */ > ,{ "feedback", PLUGIN_OFF } > + ,{ "file_key_management", PLUGIN_OFF } > }; Regards, Sergei

2 2

[Maria-developers] MDEV-8831: review request
by Nirbhay Choubey 01 Oct '15

01 Oct '15

Hi Jan, Could you please review the attached patch? Thanks, Nirbhay

1 0

[Maria-developers] Groups in PAM plugin.
by Alexey Botchkov 28 Sep '15

28 Sep '15

Hi. I came up with a small program that checks if an Unix user belongs to a group 'wheel'. That can be attached to the 'plugin/auth_pam/mapper/pam_user_map.c' in no time if that's what we want. http://myoffice.izhnet.ru/~af/gr.cc An it must be LDAP-compliant AFAIK. Best regards. HF

1 0

[Maria-developers] New Programmer(Maria-DB)
by indiavaibhav vaibhavindia 28 Sep '15

28 Sep '15

Hello everyone, My name is Vaibhav Choudhary.I am in my second year undergraduation and am new to open source. I would like to contribute to your project.Can anyone please guide me as to how should i work on a patch after i have identified the problem on JIRA? I have a good knowledge of C++ and am studying MySQL.But I am unable to figure out as to how should I go about writing the code for the issues on JIRA. Thanks Vaibhav

2 4

Re: [Maria-developers] [Commits] 1d92131: MDEV-4829 BEFORE INSERT triggers dont issue 1406 error.
by Sergei Golubchik 27 Sep '15

27 Sep '15

Hi, Holyfoot! On Sep 24, holyfoot(a)askmonty.org wrote: > revision-id: 1d92131613770b505fa462b33c1091e00d9475be (mariadb-10.1.7-61-g1d92131) > parent(s): e5418942609833edb681d16c4e2705f8c338bfee > committer: Alexey Botchkov > timestamp: 2015-09-24 14:31:06 +0500 > message: > > MDEV-4829 BEFORE INSERT triggers dont issue 1406 error. > Fixed as it's done in MySQL 5.7. > The Strict_error_handler introduced to intercept such states and is activated > in the sp_head::execute_trigger() Hmm... This is, basically, a new implementation of the strict mode. But enabled only for triggers, which is kind of weird. And potentially very fragile and inconsistent, as it's a strict mode we're talking about, it's confusing and not very consistent on itself. Having two different implementations of it doesn't help to make it clear or consistent. If you're introducing a new implementation - use it consistently everywhere. If that won't change existing intentional behavior. And please talk to Bar about his recent experiences in this area. There were also few comments about the code, see below. > diff --git a/sql/sp_head.cc b/sql/sp_head.cc > index a117963..ff6d2b4 100644 > --- a/sql/sp_head.cc > +++ b/sql/sp_head.cc > @@ -54,6 +54,35 @@ > > #include <my_user.h> > > +/** > + A simple RAII wrapper around Strict_error_handler. > +*/ > +class Strict_error_handler_wrapper > +{ > + THD *m_thd; > + Strict_error_handler m_strict_handler; > + bool m_active; > + > +public: > + Strict_error_handler_wrapper(THD *thd, sp_head *sp_head) > + : m_thd(thd), m_active(false) > + { > + if (sp_head->m_sql_mode & (MODE_STRICT_ALL_TABLES | > + MODE_STRICT_TRANS_TABLES)) > + { > + m_thd->push_internal_handler(&m_strict_handler); > + m_active= true; > + } > + } > + > + ~Strict_error_handler_wrapper() > + { > + if (m_active) > + m_thd->pop_internal_handler(); > + } > +}; Oh, really? A wrapper per handler? Make it a template, please, so that it could be used for any error handler. Like this: Error_handler_wraper<Strict_error_handler> strict_error_handler(thd, this); Also, it would be good if you do a second commit using this wrapper in other places, where appropriate. > @@ -1576,6 +1605,9 @@ sp_head::execute_trigger(THD *thd, > DBUG_ENTER("sp_head::execute_trigger"); > DBUG_PRINT("info", ("trigger %s", m_name.str)); > > + // Push Strict_error_handler if the SP was created in STRICT mode. > + Strict_error_handler_wrapper strict_wrapper(thd, this); > + > #ifndef NO_EMBEDDED_ACCESS_CHECKS > Security_context *save_ctx= NULL; > > diff --git a/sql/sql_base.cc b/sql/sql_base.cc > index 9162969..ca0699c 100644 > --- a/sql/sql_base.cc > +++ b/sql/sql_base.cc > @@ -96,6 +96,74 @@ bool No_such_table_error_handler::safely_trapped_errors() > > > /** > + Implementation of STRICT mode. > + Upgrades a set of given conditions from warning to error. > +*/ > +bool Strict_error_handler::handle_condition_ext(THD *thd, > + uint sql_errno, > + const char *sqlstate, > + Sql_condition::enum_warning_level *level, > + const char *msg, > + Sql_condition **cond_hdl) > +{ > + /* STRICT MODE should affect only the below statements */ Really? > + switch (thd->lex->sql_command) > + { > + case SQLCOM_CREATE_TABLE: > + case SQLCOM_DROP_INDEX: > + case SQLCOM_INSERT: > + case SQLCOM_REPLACE: > + case SQLCOM_REPLACE_SELECT: > + case SQLCOM_INSERT_SELECT: > + case SQLCOM_UPDATE: > + case SQLCOM_UPDATE_MULTI: > + case SQLCOM_DELETE: > + case SQLCOM_DELETE_MULTI: > + case SQLCOM_ALTER_TABLE: > + case SQLCOM_LOAD: > + case SQLCOM_CALL: > + case SQLCOM_END: > + case SQLCOM_SET_OPTION: > + case SQLCOM_SELECT: > + break; > + default: > + return false; > + } > + > + switch (sql_errno) > + { > + case ER_TRUNCATED_WRONG_VALUE: > + case ER_WRONG_VALUE_FOR_TYPE: > + case ER_WARN_DATA_OUT_OF_RANGE: > + case ER_DIVISION_BY_ZERO: > + case ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: > + case WARN_DATA_TRUNCATED: > + case ER_DATA_TOO_LONG: > + case ER_BAD_NULL_ERROR: > + case ER_NO_DEFAULT_FOR_FIELD: > + case ER_TOO_LONG_KEY: > + case ER_WRONG_ARGUMENTS: > + case ER_NO_DEFAULT_FOR_VIEW_FIELD: > + case ER_WARN_NULL_TO_NOTNULL: > + case ER_CUT_VALUE_GROUP_CONCAT: > + case ER_DATETIME_FUNCTION_OVERFLOW: > + case ER_WARN_TOO_FEW_RECORDS: > + if ((*level == Sql_condition::WARN_LEVEL_WARN) && > + thd->transaction.stmt.m_unsafe_rollback_flags == 0 || > + (thd->variables.sql_mode & MODE_STRICT_ALL_TABLES)) > + { > + (*level)= Sql_condition::WARN_LEVEL_ERROR; > + thd->killed= KILL_BAD_DATA; > + } > + break; > + default: > + break; > + } > + return false; > +} > + > + > +/** > This internal handler is used to trap ER_NO_SUCH_TABLE and > ER_WRONG_MRG_TABLE errors during CHECK/REPAIR TABLE for MERGE > tables. > diff --git a/sql/sql_base.h b/sql/sql_base.h > index 1c0029d..c5a76c5 100644 > --- a/sql/sql_base.h > +++ b/sql/sql_base.h > @@ -676,5 +676,30 @@ class No_such_table_error_handler : public Internal_error_handler > int m_unhandled_errors; > }; > > +/** > + This internal handler implements upgrade from SL_WARNING to SL_ERROR "SL_ERROR"? "SL_WARNING"? > + for the error codes affected by STRICT mode. Currently STRICT mode does > + not affect SELECT statements. > +*/ > + > +class Strict_error_handler : public Internal_error_handler > +{ > +protected: > + bool handle_condition(THD *thd, > + uint sql_errno, > + const char* sqlstate, > + Sql_condition::enum_warning_level level, > + const char* msg, > + Sql_condition ** cond_hdl) > + { DBUG_ASSERT(FALSE); return 0; } > +public: > + bool handle_condition_ext(THD *thd, > + uint sql_errno, > + const char* sqlstate, > + Sql_condition::enum_warning_level *level, > + const char* msg, > + Sql_condition ** cond_hdl); 1. why not to change handle_condition() ? 2. strict mode may change the sql_errno, handle_condition_ext doesn't support it. > +}; > + > > #endif /* SQL_BASE_INCLUDED */ Regards, Sergei

1 2

Re: [Maria-developers] [Commits] d3f10e3: MDEV-8431 Feedback plugin needs an option for http proxy.
by Sergei Golubchik 26 Sep '15

26 Sep '15

Hi, Holyfoot! On Sep 21, holyfoot(a)askmonty.org wrote: > revision-id: d3f10e30ec39bccf1172c7b2eb159f40e412bdfd (mariadb-10.0.21-14-gd3f10e3) > parent(s): abd31ca2b6cde024772fcac0f4953219d76c6344 > committer: Alexey Botchkov > timestamp: 2015-09-21 14:06:15 +0500 > message: > > MDEV-8431 Feedback plugin needs an option for http proxy. > 'feedback_proxy_server' system variable added to specify the > proxy server. Not a dynamic one. How did you test this feature? > diff --git a/plugin/feedback/feedback.cc b/plugin/feedback/feedback.cc > index f644bd5..f76c52a 100644 > --- a/plugin/feedback/feedback.cc > +++ b/plugin/feedback/feedback.cc > @@ -250,6 +251,9 @@ static int init(void *p) > > prepare_linux_info(); > > + proxy_url= proxy_server ? > + Url::create(proxy_server, strlen(proxy_server)) : 0; Some diagnostics would be nice here. At least "feedback: invalid proxy url: '%.*s'". See how ivalid feedback urls are reported. > + > url_count= 0; > if (*url) > { > @@ -347,6 +354,9 @@ static MYSQL_SYSVAR_ULONG(send_timeout, send_timeout, PLUGIN_VAR_RQCMDARG, > static MYSQL_SYSVAR_ULONG(send_retry_wait, send_retry_wait, PLUGIN_VAR_RQCMDARG, > "Wait this many seconds before retrying a failed send.", > NULL, NULL, 60, 1, 60*60*24, 1); > +static MYSQL_SYSVAR_STR(proxy_server, proxy_server, > + PLUGIN_VAR_READONLY | PLUGIN_VAR_RQCMDARG, > + "Proxy server address.", NULL, NULL,0); Mention that it must be an url. "Proxy server URL" or "Proxy server address, in the correct URI format", or something. > static struct st_mysql_sys_var* settings[] = { > MYSQL_SYSVAR(server_uid), > diff --git a/plugin/feedback/url_http.cc b/plugin/feedback/url_http.cc > index f214f7a..eade67c 100644 > --- a/plugin/feedback/url_http.cc > +++ b/plugin/feedback/url_http.cc > @@ -148,9 +148,12 @@ int Url_http::send(const char* data, size_t data_length) > my_socket fd= INVALID_SOCKET; > char buf[1024]; > uint len= 0; > + Url_http *proxy_loc= (Url_http *) proxy_url; > > addrinfo *addrs, *addr, filter= {0, AF_UNSPEC, SOCK_STREAM, 6, 0, 0, 0, 0}; > - int res= getaddrinfo(host.str, port.str, &filter, &addrs); > + int res= proxy_url ? > + getaddrinfo(proxy_loc->host.str, proxy_loc->port.str, &filter, &addrs) : > + getaddrinfo(host.str, port.str, &filter, &addrs); > First, you don't know whether proxy_url is Url_http. It might be easier to have an option --feedback-http-proxy=host:port (not the url). It also solves the potential future confusion if we'll have more than one transport. Second, I don't think proxies work this way at all, for a http proxy, you need to specify the host in th GET request, like POST http://foo.bar/bla/bla So, I think, a better implementation would be to take proxy into account not in Url_http::send(), but already in http_create(). And create Url_http objects for feedback url with proxy's host and port, and with the appropriately adjusted path. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] efcbbed: MDEV-8682 - CSV engine does not properly process "", in quotes
by Sergei Golubchik 26 Sep '15

26 Sep '15

Hi, Sergey! On Sep 22, Sergey Vojtovich wrote: > revision-id: efcbbed977dfcd9ee0ed035cbb0df4404483b0c8 (mariadb-10.1.7-53-gefcbbed) > parent(s): 7cbecadf9b59d06f4d9a9e776f99418b273c2ebc > committer: Sergey Vojtovich > timestamp: 2015-09-22 16:52:30 +0400 > message: > > MDEV-8682 - CSV engine does not properly process "", in quotes > > Added per-table boolean IETF_QUOTES variable to CSV storage engine. It allows to > enable IETF-compatible parsing of embedded quote and comma characters. Disabled > by default. > > This patch is based on Percona revision: > https://github.com/percona/percona-server/commit/b32fbf02766f8db00f9ff4e6dc… > > Note that original patch adds server variable, while this patch adds per-table > variable. I agree that a per-table option is safer. Ok to push. Regards, Sergei

1 0