- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] f39b9e0: MDEV-7526: TokuDB doesn't build on OS X
by Sergei Golubchik 20 Dec '15

20 Dec '15

Hi, Vicentiu! On Dec 19, Vicentiu Ciorbaru wrote: > revision-id: f39b9e04db1e71e72bfc19174f257db5147df440 (mariadb-5.5.47-9-gf39b9e0) > parent(s): 64149590c47d1cf6b1b227d8c90bdc23d20a8956 > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2015-12-19 14:14:16 +0200 > message: > > MDEV-7526: TokuDB doesn't build on OS X > > Removed unused functions from tokudb_dump.cc. ok to push Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org -- Vote for my Percona Live 2016 talks: https://www.percona.com/live/data-performance-conference-2016/sessions/mari… https://www.percona.com/live/data-performance-conference-2016/sessions/mari…

1 0

Re: [Maria-developers] [Commits] f89c9fc: MDEV-7526: TokuDB doesn't build on OS X
by Sergei Golubchik 20 Dec '15

20 Dec '15

Hi, Vicentiu! On Dec 19, Vicentiu Ciorbaru wrote: > revision-id: f89c9fc4b7b5d82c79775cb848225900b45a6b79 (mariadb-5.5.47-7-gf89c9fc) > parent(s): 0ed474484c037a32bea32abaecd3ff770f40bd49 > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2015-12-19 14:14:05 +0200 > message: > > MDEV-7526: TokuDB doesn't build on OS X > > This patch fixes one compilation error related to __db_lsn struct. The > struct can not be defined as empty according to the main C standard. > In C++, this is handled by forcing a size of 1. To eliminate the error > we add a dummy char field of size 1. This has no effect on the C++ > compiled code, but also removes the compiler error. > > --- > storage/tokudb/ft-index/buildheader/make_tdb.cc | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/storage/tokudb/ft-index/buildheader/make_tdb.cc b/storage/tokudb/ft-index/buildheader/make_tdb.cc > index 5370664..610ce67 100644 > --- a/storage/tokudb/ft-index/buildheader/make_tdb.cc > +++ b/storage/tokudb/ft-index/buildheader/make_tdb.cc > @@ -481,7 +481,9 @@ static void print_db_key_range_struct (void) { > > static void print_db_lsn_struct (void) { > field_counter=0; > - sort_and_dump_fields("db_lsn", false, NULL); > + /* A dummy field to make sizeof(DB_LSN) equal in C and C++ */ > + const char *extra[] = { "char dummy", NULL }; > + sort_and_dump_fields("db_lsn", false, extra); > } seems like a backport from 10.0. ok to push Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org -- Vote for my Percona Live 2016 talks: https://www.percona.com/live/data-performance-conference-2016/sessions/mari… https://www.percona.com/live/data-performance-conference-2016/sessions/mari…

1 0

[Maria-developers] MDEV-9181 (NULLIF(table.col)0) gives wrong result on 10.1.x
by Alexander Barkov 18 Dec '15

18 Dec '15

Hi Sergei, Please find a prototype patch for MDEV-9181 attached. It works, but I'm not fully sure. Any better ideas? Thanks.

1 0

[Maria-developers] New mariadb.org in the works
by Otto Kekäläinen 18 Dec '15

18 Dec '15

Hello! We are about to renew the mariadb.org website. The idea is to replace the current mariadb.org and blog.mariadb.org with one single site that includes both the basic information about the software project and the MariaDB Foundation, as well as the blog. Work in progress is visible at https://new.mariadb.org/ Please send us your feedback!

1 1

[Maria-developers] Unsubscribe
by Abdul Hakeem 17 Dec '15

17 Dec '15

2 1

Re: [Maria-developers] [Commits] 732d45e: MDEV-8378 - Debian: the Lintian complains about many "shlib-calls-exit" in many
by Sergei Golubchik 16 Dec '15

16 Dec '15

Hi, Sergey! On Dec 14, Sergey Vojtovich wrote: > revision-id: 732d45e93b81a104e3f3931e4908e22167a54622 (mariadb-10.0.22-57-g732d45e) > parent(s): 3e206a518dec400e084451165f633b78eb2e7fee > committer: Sergey Vojtovich > timestamp: 2015-12-14 15:27:09 +0400 > message: > > MDEV-8378 - Debian: the Lintian complains about many "shlib-calls-exit" in many > of the plugins > > Fixed exit/_exit calls from libdaemon_example.so, libmysqlclient.so, > libmysqlclient_r.so, libmysqld.so. > > Note: this is just rough prototype, not to be pushed. libmysqld.so still has > a bunch of exit/_exit calls from InnoDB. > > diff --git a/mysys/my_addr_resolve.c b/mysys/my_addr_resolve.c > index 90e6f43..276d5aa 100644 > --- a/mysys/my_addr_resolve.c > +++ b/mysys/my_addr_resolve.c > @@ -190,7 +190,7 @@ const char *my_addr_resolve_init() > close(out[0]); > close(out[1]); > execlp("addr2line", "addr2line", "-C", "-f", "-e", my_progname, NULL); > - exit(1); > + abort(); ok > } > > close(in[0]); > diff --git a/mysys/my_default.c b/mysys/my_default.c > index 8faee00..7bf86f2 100644 > --- a/mysys/my_default.c > +++ b/mysys/my_default.c > @@ -631,7 +631,7 @@ int my_load_defaults(const char *conf_file, const char **groups, > if (!my_getopt_is_args_separator((*argv)[i])) /* skip arguments separator */ > printf("%s ", (*argv)[i]); > puts(""); > - exit(0); > + abort(); /* !!! */ not ok. --print-defaults means exit(0), not abort() > } > > if (default_directories) > @@ -641,7 +641,7 @@ int my_load_defaults(const char *conf_file, const char **groups, > > err: > fprintf(stderr,"Fatal error in defaults handling. Program aborted\n"); > - exit(1); > + abort(); ok > return 0; /* Keep compiler happy */ > } > > diff --git a/mysys/my_malloc.c b/mysys/my_malloc.c > index e5332301..111bc7f 100644 > --- a/mysys/my_malloc.c > +++ b/mysys/my_malloc.c > @@ -108,7 +108,7 @@ void *my_malloc(size_t size, myf my_flags) > my_error(EE_OUTOFMEMORY, MYF(ME_BELL + ME_WAITTANG + > ME_NOREFRESH + ME_FATALERROR),size); > if (my_flags & MY_FAE) > - exit(1); > + abort(); no, MY_FAE means exit(1) not abort() > } > else > { > diff --git a/mysys/my_static.c b/mysys/my_static.c > index 84d2dc6..4272c24 100644 > --- a/mysys/my_static.c > +++ b/mysys/my_static.c > @@ -72,7 +72,8 @@ ulong my_time_to_wait_for_lock=2; /* In seconds */ > #ifdef SHARED_LIBRARY > const char *globerrs[GLOBERRS]; /* my_error_messages is here */ > #endif > -void (*my_abort_hook)(int) = (void(*)(int)) exit; > +void my_abort_wrapper(int a __attribute__((unused))) { abort(); } > +void (*my_abort_hook)(int)= my_abort_wrapper; whatever, it's never used, as far as I can see. It can as well be removed. > void (*error_handler_hook)(uint error, const char *str, myf MyFlags)= > my_message_stderr; > void (*fatal_error_handler_hook)(uint error, const char *str, myf MyFlags)= > diff --git a/mysys/typelib.c b/mysys/typelib.c > index 75744a6..ec1e8fb 100644 > --- a/mysys/typelib.c > +++ b/mysys/typelib.c > @@ -51,7 +51,7 @@ int find_type_or_exit(const char *x, TYPELIB *typelib, const char *option) > if ((res= find_type_with_warning(x, typelib, option)) <= 0) > { > sf_leaking_memory= 1; /* no memory leak reports here */ > - exit(1); > + abort(); no, it's find_type_or_exit, not find_type_or_abort. Incorrect option on the command line should not cause SIGABRT. > } > return res; > } > diff --git a/plugin/daemon_example/daemon_example.cc b/plugin/daemon_example/daemon_example.cc > index dbc3c5c..cdea632 100644 > --- a/plugin/daemon_example/daemon_example.cc > +++ b/plugin/daemon_example/daemon_example.cc > @@ -129,7 +129,7 @@ static int daemon_example_plugin_init(void *p __attribute__ ((unused))) > (void *)con) != 0) > { > fprintf(stderr,"Could not create heartbeat thread!\n"); > - exit(0); > + DBUG_RETURN(1); ok > } > plugin->data= (void *)con; > > diff --git a/sql-common/client.c b/sql-common/client.c > index d20759c..7a4efc3 100644 > --- a/sql-common/client.c > +++ b/sql-common/client.c > @@ -1219,7 +1219,7 @@ void mysql_read_default_options(struct st_mysql_options *options, > FIND_TYPE_BASIC)) <= 0) > { > fprintf(stderr, "Unknown option to protocol: %s\n", opt_arg); > - exit(1); > + abort(); No way. An application should not SIGABRT on the invalid values in the my.cnf file. It should not exit either, in fact, but it's a different issue. > } > break; > case OPT_shared_memory_base_name: > diff --git a/sql/signal_handler.cc b/sql/signal_handler.cc > index 3fadbcd..b301b4c 100644 > --- a/sql/signal_handler.cc > +++ b/sql/signal_handler.cc > @@ -69,7 +69,7 @@ extern "C" sig_handler handle_fatal_signal(int sig) > if (segfaulted) > { > my_safe_printf_stderr("Fatal " SIGNAL_FMT " while backtracing\n", sig); > - _exit(1); /* Quit without running destructors */ > + abort(); Heh, no. You don't want to send another signal when you've encountered an fatal error inside the signal handler. ... etc ... Are you sure we want to fix that at all? And if yes - is it something we need to bother fixing now? How comes it's "critical"? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org -- Vote for my Percona Live 2016 talks: https://www.percona.com/live/data-performance-conference-2016/sessions/mari… https://www.percona.com/live/data-performance-conference-2016/sessions/mari…

2 2

Re: [Maria-developers] [Commits] 0b0d341: MDEV-9044 : Binlog corruption in Galera
by Sergei Golubchik 16 Dec '15

16 Dec '15

Hi, Nirbhay! On Dec 07, Nirbhay Choubey wrote: > revision-id: 0b0d34138300b891ccbec58e01f3ab5bebe24d71 > parent(s): 3c0e9d31b3e6494931deb09f5c93b05a96df8471 > committer: Nirbhay Choubey > branch nick: 10.1.b9044 > timestamp: 2015-12-07 14:01:52 -0500 > message: > > MDEV-9044 : Binlog corruption in Galera > > While refreshing the IO_CACHE, do not update its parameters (read_pos, > read_end & pos_in_file) if there is nothing left to read. I'm sorry, but I don't understand the fix. Why should parameters be not updated? If there's nothing left to read, the cache is marked as empty, that seems to be correct. > diff --git a/mysys/mf_iocache.c b/mysys/mf_iocache.c > index 28e5e72..db8d0b5 100644 > --- a/mysys/mf_iocache.c > +++ b/mysys/mf_iocache.c > @@ -663,7 +663,11 @@ int _my_b_cache_read(IO_CACHE *info, uchar *Buffer, size_t Count) > info->error= (int) left_length; > DBUG_RETURN(1); > } > - length=0; /* Didn't read any chars */ > + else > + { > + info->error= 0; > + DBUG_RETURN(0); /* EOF */ > + } > } Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org -- Vote for my Percona Live 2016 talks: https://www.percona.com/live/data-performance-conference-2016/sessions/mari… https://www.percona.com/live/data-performance-conference-2016/sessions/mari…

1 0

Re: [Maria-developers] [Commits] 9d8ad0d: Add --persistent option for mysqlcheck
by Sergey Vojtovich 15 Dec '15

15 Dec '15

Hi Vicentu, this is contribution by Daniel. He should get some credit for this. Assuming you didn't change this code much, this should be committed on Daniel's behalf, so that he gets credit on github. Or at the very least mention in a comment contribution author. Thanks, Sergey On Tue, Dec 15, 2015 at 11:11:50AM +0200, Vicentiu Ciorbaru wrote: > revision-id: 9d8ad0d79e3c3a1a9bf7c8cc6477ee4e69fba633 (mariadb-10.0.22-63-g9d8ad0d) > parent(s): e9b4a041af5122dffd59012493c565e6e3db2664 > committer: Vicențiu Ciorbaru > timestamp: 2015-12-15 11:11:28 +0200 > message: > > Add --persistent option for mysqlcheck > > 10.0 has an "analyze table .. persistent for all" syntax. This adds > --persistent to mysqlcheck(mysqlanalyize) to perform this extended > analyze table option. > > --- > client/mysqlcheck.c | 6 +++++- > man/mysqlcheck.1 | 18 +++++++++++++++++- > 2 files changed, 22 insertions(+), 2 deletions(-) > > diff --git a/client/mysqlcheck.c b/client/mysqlcheck.c > index ead4127..b9e5478 100644 > --- a/client/mysqlcheck.c > +++ b/client/mysqlcheck.c > @@ -43,7 +43,7 @@ static my_bool opt_alldbs = 0, opt_check_only_changed = 0, opt_extended = 0, > opt_silent = 0, opt_auto_repair = 0, ignore_errors = 0, > tty_password= 0, opt_frm= 0, debug_info_flag= 0, debug_check_flag= 0, > opt_fix_table_names= 0, opt_fix_db_names= 0, opt_upgrade= 0, > - opt_do_tables= 1; > + opt_persistent_all= 0, opt_do_tables= 1; > static my_bool opt_write_binlog= 1, opt_flush_tables= 0; > static uint verbose = 0, opt_mysql_port=0; > static int my_end_arg; > @@ -160,6 +160,9 @@ static struct my_option my_long_options[] = > {"password", 'p', > "Password to use when connecting to server. If password is not given, it's solicited on the tty.", > 0, 0, 0, GET_STR, OPT_ARG, 0, 0, 0, 0, 0, 0}, > + {"persistent", 'Z', "When using ANALYZE TABLE use the PERSISTENT FOR ALL option.", > + &opt_persistent_all, &opt_persistent_all, 0, GET_BOOL, NO_ARG, 0, 0, > + 0, 0, 0, 0}, > #ifdef __WIN__ > {"pipe", 'W', "Use named pipes to connect to server.", 0, 0, 0, GET_NO_ARG, > NO_ARG, 0, 0, 0, 0, 0, 0}, > @@ -909,6 +912,7 @@ static int handle_request_for_tables(char *tables, size_t length, my_bool view) > case DO_ANALYZE: > DBUG_ASSERT(!view); > op= (opt_write_binlog) ? "ANALYZE" : "ANALYZE NO_WRITE_TO_BINLOG"; > + if (opt_persistent_all) end = strmov(end, " PERSISTENT FOR ALL"); > break; > case DO_OPTIMIZE: > DBUG_ASSERT(!view); > diff --git a/man/mysqlcheck.1 b/man/mysqlcheck.1 > index c175483..e05bbf8 100644 > --- a/man/mysqlcheck.1 > +++ b/man/mysqlcheck.1 > @@ -1,6 +1,6 @@ > '\" t > .\" > -.TH "\FBMYSQLCHECK\FR" "1" "04/08/2015" "MariaDB 10\&.0" "MariaDB Database System" > +.TH "\FBMYSQLCHECK\FR" "1" "27/12/2015" "MariaDB 10\&.0" "MariaDB Database System" > .\" ----------------------------------------------------------------- > .\" * set default formatting > .\" ----------------------------------------------------------------- > @@ -677,6 +677,22 @@ Specifying a password on the command line should be considered insecure\&. You c > .sp -1 > .IP \(bu 2.3 > .\} > +.\" mysqlcheck: persisent option > +.\" persistent option: mysql > +\fB\-\-persistent\fR, > +\fB\-Z\fR > +.sp > +Used with ANALYZE TABLE to append the option PERSISENT FOR ALL. > +.RE > +.sp > +.RS 4 > +.ie n \{\ > +\h'-04'\(bu\h'+03'\c > +.\} > +.el \{\ > +.sp -1 > +.IP \(bu 2.3 > +.\} > .\" mysqlcheck: pipe option > .\" pipe option: mysql > \fB\-\-pipe\fR, > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 2

[Maria-developers] MDEV-8721 AIX: Compile error xtradb:log0log.cc
by Alexander Barkov 15 Dec '15

15 Dec '15

Hi Jan, Can you please review a patch for: MDEV-8721 AIX: Compile error xtradb:log0log.cc which seems to be the same bug with: MDEV-8516 AIX xtradb -> log -> log0log.cc.o Note, I don't have an AIX 7 machine. Just applying the fix suggested by the complainer. The fix looks fine for me. Thanks.

1 0

[Maria-developers] gsoc 2016 and Contributing to MariaDB
by Malith Jayaweera 13 Dec '15

13 Dec '15

Hi! I'm a student and am very much interested in contributing to Maria db. I'm new to development and I haven't got a clue as to where to start. Any sort of guidance is highly appreciated. Thanks. Malith

1 0