- developers - lists.mariadb.org

[Maria-developers] MTR related community contribution
by Vicențiu Ciorbaru 07 Feb '16

07 Feb '16

Hi Vlad, I'm looking at the community pull request https://github.com/grooverdan/mariadb-server/commit/a9dfee63bad7393002621f9… I have a question regarding your commit: 2943d2b7e99b4221ef481890fc9a56ad569f3985 The contribution aims to remove the hard limit of 50 unique ids as it seems to cause problems for some use cases with a lot of proceeses. It does this by either leaving it at 50 or to be equal to the number of spawned processes. I'm thinking that even setting the limit of unique ids to num_processes might cause problems if there is another mtr running in parallel and both have > 50 processes. This is probably minor but why set this limit so low? Wouldn't a larger number (say 10k) be ok? Or why not generate a random number and lock a file with that number? (if the random number is invalid, generate a new one. On average it should finish quite quickly) Thanks, Vicentiu

3 2

[Maria-developers] Invalid code in server_audit.c
by Vicențiu Ciorbaru 06 Feb '16

06 Feb '16

Hi Alexei, While investigating community contributions from Daniel Black (MDEV-9433), I came across this comment: [image: danblack]Daniel Black <https://mariadb.atlassian.net/secure/ViewProfile.jspa?name=danblack> added a comment - 2016-01-20 02:54 [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE'. [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE;HUGETLB_USE_PROC_MEMINFO'. [plugin/server_audit/server_audit.c:402]: (error) Invalid number of character '{' when these macros are defined: 'DBUG_VOID_RETURN=return;DBUG_RETURN(a)=return a;HAVE_PSI_INTERFACE;USE_ALARM_THREAD'. Exists in 5.5 https://github.com/MariaDB/server/blob/5.5/plugin/server_audit/server_audit… Remove second {{ I've had a look at the code mentioned there and key_LOCK_bigbuffer does not exist anywhere else. Since we're not getting any compilation issues, it means we're not compiling that bit of code due to the defines. This indeed is so, as MYSQL_DYNAMIC_PLUGIN is defined for that file on the default cmake config which leads to FLOGGER being defined. I could not figure out a way to actually compile the code with defines such that that bit of code actually compiles. Either way it would not compile, due to the missing symbol. Do you think that we should just remove the line that mentions key_LOCK_bigbuffer? Also, since this is something we have not caught during testing, can we test for this compilation configuration somehow? Vicentiu

1 0

[Maria-developers] MariaDB JIRA is moving
by Rasmus Johansson 05 Feb '16

05 Feb '16

The MariaDB JIRA instance that currently is in use for project and issue tracking will change. The current instance is hosted in Atlassian's cloud and it has worked well, but we have hit the maximum user limit of 2000 users. It's fantastic to see how many of you actually report bugs and other issues in the MariaDB project! To hit that limit also means that we have to migrate over to a self-hosted instance of JIRA. Below are important details about that change. When will the switch happen: Sat 27th of Feb What is the impact for me as a user of MariaDB's JIRA: 1. URL change - The current instance is hosted in Atalassian's cloud and has the URL mariadb.atlassian.net. The new one will be found at jira.mariadb.org starting from 28th of Feb. 2. RSS feeds - If you have been using JIRA's RSS feeds, you'll need to set up them again since the URL is changing What will happen to old JIRA: The mariadb.atlassian.net JIRA instance will be put into read-only mode and a banner will be visible on each page telling the URL of the new MariaDB JIRA instance. It will remain this way for some time since it has been referenced quite heavily from other sites. source: https://mariadb.org/mariadb-jira-is-moving/ -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

1 0

[Maria-developers] MDEV-8691 Multiple test failures on mips and mipsel platforms, suites federated and rpl
by Alexander Barkov 02 Feb '16

02 Feb '16

Hi Jan, can you please have a look into: https://mariadb.atlassian.net/browse/MDEV-8691 Otto managed to get a stack trace from mips machine. It seems to crash inside InnoDB. Thanks. #3 <signal handler called> #4 0x000000fff6b48e80 in std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*) () from /usr/lib/mips64el-linux-gnuabi64/libstdc++.so.6 #5 0x00000001207cf878 in std::__cxx11::list<unsigned char*, std::allocator<unsigned char*> >::_M_insert (__x=<synthetic pointer>, __position=..., this=0x118) at /usr/include/c++/5/bits/stl_list.h:1755 #6 std::__cxx11::list<unsigned char*, std::allocator<unsigned char*> >::push_back (__x=<synthetic pointer>, this=0x118) at /usr/include/c++/5/bits/stl_list.h:1089 #7 recv_dblwr_t::add (this=0x118, page=0xffeb004000 "\377\060~$") at /«PKGBUILDDIR»/storage/xtradb/log/log0recv.cc:4077 #8 0x00000001208df7f8 in buf_dblwr_init_or_load_pages (file=<optimized out>, path=0xfff678b029 <srv_read_only_mode> "", load_corrupt_pages=<optimized out>) at /«PKGBUILDDIR»/storage/xtradb/buf/buf0dblwr.cc:457 #9 0x000000fff66e42bc in open_or_create_data_files (sum_of_new_sizes=<synthetic pointer>, max_flushed_lsn=0xffffa89a50, min_flushed_lsn=0xffffa89a48, create_new_db=<synthetic pointer>) at /«PKGBUILDDIR»/storage/innobase/srv/srv0start.cc:1033 #10 innobase_start_or_create_for_mysql () at /«PKGBUILDDIR»/storage/innobase/srv/srv0start.cc:2105 #11 0x000000fff65f0028 in innobase_init (p=<optimized out>) at /«PKGBUILDDIR»/storage/innobase/handler/ha_innodb.cc:3400 #12 0x00000001204a17bc in ha_initialize_handlerton (plugin=0xfff5cb49f0) at /«PKGBUILDDIR»/sql/handler.cc:501 #13 0x00000001202fcafc in plugin_initialize (tmp_root=0xffffa91c40, tmp_root@entry=0x0, plugin=plugin@entry=0xfff5cb49f0, argc=0x120fdf680 <remaining_argc>, argc@entry=0x6, argv=0xfff5c7cc58, argv@entry=0xfd8, options_only=<optimized out>) at /«PKGBUILDDIR»/sql/sql_plugin.cc:1379 #14 0x00000001202fd7b0 in plugin_init (argc=0x6, argv=0xfd8, flags=<optimized out>) at /«PKGBUILDDIR»/sql/sql_plugin.cc:1659 #15 0x00000001202347ec in init_server_components () at /«PKGBUILDDIR»/sql/mysqld.cc:4850 #16 0x000000012023b83c in mysqld_main (argc=255, argv=0xff00000000) at /«PKGBUILDDIR»/sql/mysqld.cc:5445 #17 0x000000012021cf18 in main (argc=<optimized out>, argv=<optimized out>) at /«PKGBUILDDIR»/sql/main.cc:25

2 2

Re: [Maria-developers] 9f2e2d8: [MDEV-7978] Update grammar for new syntax
by Sergei Golubchik 02 Feb '16

02 Feb '16

Hi, Vicentiu! On Jan 19, Vicentiu Ciorbaru wrote: > revision-id: 9f2e2d89917709f9223fe2d4b75dc86d0297b4c4 (mariadb-10.1.8-113-g9f2e2d8) > parent(s): 83e197aa6bd3a7eb81482795732bfbdb3b415deb > author: Vicențiu Ciorbaru > committer: Vicențiu Ciorbaru > timestamp: 2016-01-17 17:07:21 +0200 > message: > > [MDEV-7978] Update grammar for new syntax > > Extend the syntax accepted by the grammar to account for the new create user > and alter user syntax. a couple of comments: > diff --git a/sql/sql_yacc.yy b/sql/sql_yacc.yy > index 3eb6a99..c1f4249 100644 > --- a/sql/sql_yacc.yy > +++ b/sql/sql_yacc.yy > @@ -7279,6 +7280,11 @@ alter: > lex->sql_command= SQLCOM_ALTER_SERVER; > lex->server_options.reset($3); > } OPTIONS_SYM '(' server_options_list ')' { } > + | ALTER opt_if_exists USER clear_privileges user_list > + require_clause resource_options > + { please, add a comment that "ALTER USER foo;" is allowed for MySQL compatibility > + Lex->sql_command= SQLCOM_ALTER_USER; > + } > ; > > ev_alter_on_schedule_completion: > @@ -15734,6 +15724,37 @@ grant_option: > } > ; > > +resource_option_list: > + resource_option_list resource_option {} > + | resource_option {} > + ; > + > +resource_options: better rename it to opt_resource_options (and opt_grant_options below) for consistency. In sql_yacc.yy optional clauses often start with opt_ and one can immediately see that they're optional in, for example | ALTER opt_if_exists USER clear_privileges user_list opt_require_clause opt_resource_options > + /* empty */ {} > + | WITH resource_option_list > + ; > + > + > +grant_options: > + /* empty */ {} > + | WITH grant_option_list {} > + ; Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-9415 Crash with ConnectSE + MySQL ODBC driver + INSERT
by Alexander Barkov 02 Feb '16

02 Feb '16

Hi Georg, Can you please have a look into: https://mariadb.atlassian.net/browse/MDEV-9415 ConnectSE crashes on INSERT statements inside the ODBC driver, while UPDATE, SELECT, DELETE work fine. Any ideas how to track down the problem? Thanks.

1 1

Re: [Maria-developers] [Commits] 5dd6eb4: MDEV-9117: Client Server capability negotiation for MariaDB specific functionality
by Sergei Golubchik 01 Feb '16

01 Feb '16

Hi, Sanja! On Jan 28, OleksandrByelkin wrote: > revision-id: 5dd6eb45c418f61c749a7884d7b3e13d62f3bfb9 (mariadb-10.1.8-113-g5dd6eb4) > parent(s): 14d79a5e99f9992cabb7489203989ccdaacadb78 > committer: Oleksandr Byelkin > timestamp: 2016-01-28 14:58:12 +0100 > message: > > MDEV-9117: Client Server capability negotiation for MariaDB specific functionality Just a couple of comments: > New capability flags space. > Removed old progress flag, added new one. > > diff --git a/client/mysql.cc b/client/mysql.cc > index 3e08c87..715eed8 100644 > --- a/client/mysql.cc > +++ b/client/mysql.cc > @@ -152,7 +152,7 @@ static ulong opt_max_allowed_packet, opt_net_buffer_length; > static uint verbose=0,opt_silent=0,opt_mysql_port=0, opt_local_infile=0; > static uint my_end_arg; > static char * opt_mysql_unix_port=0; > -static int connect_flag=CLIENT_INTERACTIVE; > +static ulong connect_flag=CLIENT_INTERACTIVE; ulong width is not portable, remember trubles we had with ulong sysvars? better use ulonglong for 64bit and uint for 32bit. > static my_bool opt_binary_mode= FALSE; > static int interrupted_query= 0; > static char *current_host,*current_db,*current_user=0,*opt_password=0, > diff --git a/libmysql/client_settings.h b/libmysql/client_settings.h > index b233614..2577870 100644 > --- a/libmysql/client_settings.h > +++ b/libmysql/client_settings.h > @@ -27,7 +27,7 @@ extern char * mysql_unix_port; > When adding capabilities here, consider if they should be also added to > the server's version. > */ > -#define CLIENT_CAPABILITIES (CLIENT_LONG_PASSWORD | \ > +#define CLIENT_CAPABILITIES (CLIENT_MYSQL | \ really? CLIENT_MYSQL? Is it because they aren't using Connector/C yet? > CLIENT_LONG_FLAG | \ > CLIENT_TRANSACTIONS | \ > CLIENT_PROTOCOL_41 | \ > diff --git a/sql/sql_acl.cc b/sql/sql_acl.cc > index 2bcd351..dcb12e6 100644 > --- a/sql/sql_acl.cc > +++ b/sql/sql_acl.cc > @@ -11730,18 +11731,27 @@ static ulong parse_client_handshake_packet(MPVIO_EXT *mpvio, > */ > DBUG_ASSERT(net->read_pos[pkt_len] == 0); > > - ulong client_capabilities= uint2korr(net->read_pos); > + ulonglong client_capabilities= uint2korr(net->read_pos); > + compile_time_assert(sizeof(client_capabilities) >= 8); > if (client_capabilities & CLIENT_PROTOCOL_41) > { > - if (pkt_len < 4) > + if (pkt_len < 32) > return packet_error; > client_capabilities|= ((ulong) uint2korr(net->read_pos+2)) << 16; > + if (!(client_capabilities & CLIENT_MYSQL)) > + { > + // it is client with mariadb extensions > + ulonglong ext_client_capabilities= > + (((ulonglong)uint4korr(net->read_pos + 28)) << 32); > + client_capabilities|= ext_client_capabilities; > + } As I wrote earlier, please add here else if (client_capabilities & CLIENT_PROGRESS_OBSOLETE) client_capabilities|= MARIADB_CLIENT_PROGRESS; > } > > /* Disable those bits which are not supported by the client. */ > + compile_time_assert(sizeof(thd->client_capabilities) >= 8); > thd->client_capabilities&= client_capabilities; > > - DBUG_PRINT("info", ("client capabilities: %lu", thd->client_capabilities)); > + DBUG_PRINT("info", ("client capabilities 1: %llu", thd->client_capabilities)); why " 1" ? > if (thd->client_capabilities & CLIENT_SSL) > { > unsigned long errptr __attribute__((unused)); Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

2 1

[Maria-developers] Error creating new list
by Sonali Ellath 01 Feb '16

01 Feb '16

Hi, I built mailman-bundler using the guidelines found here <https://gitlab.com/mailman/mailman-bundler>. Server started successfully and and I created few domains. It worked well but when I tried to create a list, I received HTTP Error 500: A server error occurred. Please contact the administrator. Traceback: Traceback (most recent call last): File "/usr/lib/python3.4/wsgiref/handlers.py", line 137, in run self.result = application(self.environ, self.start_response) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/database/transaction.py", line 57, in wrapper rtn = function(*args, **kws) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/rest/wsgiapp.py", line 65, in __call__ environ, start_response) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/falcon/api.py", line 182, in __call__ responder(req, resp, **params) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/rest/lists.py", line 206, in on_post mlist = create_list(**validator(request)) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/app/lifecycle.py", line 81, in create_list call_name(config.mta.incoming).create(mlist) File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/mta/postfix.py", line 69, in create self.regenerate() File "github/mailman/mailman-bundler/venv-3.4/lib/python3.4/site-packages/mailman/mta/postfix.py", line 104, in regenerate raise RuntimeError(NL.join(errors)) RuntimeError: command failure: /usr/sbin/postmap github/mailman/mailman-bundler/var/data/postfix_lmtp, 127, Key has expired command failure: /usr/sbin/postmap github/mailman/mailman-bundler/var/data/postfix_domains, 127, Key has expired Domain Details: Mail Host: lists.example.com URL Host: http://lists.example.com Please Help! Thanks - Sonali

2 1

[Maria-developers] Non-bloking API problem on non-x86 (MDEV-9112)
by Kristian Nielsen 01 Feb '16

01 Feb '16

Hi Georg, I stumbled upon the problem in the server source tree that ucontext check is broken, causing the non-blocking library to be completely disabled on all non-x86 platforms. After creating my own patch, I noticed that you alrady made a patch for this in MDEV-9112, but it does not appear to be pushed yet. Do you still want to push your patch? The patch looks fine (you can take this as review), it handles a couple things I forgot in my own patch. I think this should definitely go in 10.0 (and 10.1) - but do you think it should go in 5.5 also (not sure)? - Kristian. PS. I supplied a patch in CONC-153 for the similar problem in mariadb-connector-c, but maybe you are already aware of that as well. It was BTW cool to see that an application of mine (originally written against libmysqlclient) worked without changes on mariadb-connector-c.

1 1

Re: [Maria-developers] [Commits] 2a181ea: MDEV-8713 Add continuous binary log backup to mysqlbinlog.
by Sergei Golubchik 31 Jan '16

31 Jan '16

Hi, Alexey! On Nov 27, Alexey Botchkov wrote: > revision-id: 2a181ea7b16dcbc6dd30af5a2396760261d7d500 (mariadb-10.1.8-81-g2a181ea) > parent(s): 9d5c9379a6fd3662d4388cda177a3b1ea7b070cc > committer: Alexey Botchkov > timestamp: 2015-11-27 16:33:23 +0400 > message: > > MDEV-8713 Add continuous binary log backup to mysqlbinlog. > diff --git a/client/client_priv.h b/client/client_priv.h > index 656c8fc..44f0b21 100644 > --- a/client/client_priv.h > +++ b/client/client_priv.h > @@ -92,6 +92,7 @@ enum options_client > OPT_REPORT_PROGRESS, > OPT_SKIP_ANNOTATE_ROWS_EVENTS, > OPT_SSL_CRL, OPT_SSL_CRLPATH, > + OPT_RAW_OUTPUT, OPT_WAIT_SERVER_ID, OPT_STOP_NEVER, 1. There's no need to create named constants for OPT_RAW_OUTPUT and OPT_WAIT_SERVER_ID - they are never used anywhere. Simply put 0 in the my_options structure instead. 2. OPT_STOP_NEVER is used in the switch, so it needs a named constant. but it still doesn't have to be in client_priv.h, it's not an option common to all clients. Define it in mysqlbinlog.cc (see how mysqltest.cc and mysql_upgrade.c do it) > OPT_MAX_CLIENT_OPTION /* should be always the last */ > }; > > diff --git a/client/mysqlbinlog.cc b/client/mysqlbinlog.cc > index 5b07232..a2509b7 100644 > --- a/client/mysqlbinlog.cc > +++ b/client/mysqlbinlog.cc > @@ -96,6 +98,8 @@ static char* database= 0; > static my_bool force_opt= 0, short_form= 0, remote_opt= 0; > static my_bool debug_info_flag, debug_check_flag; > static my_bool force_if_open_opt= 1; > +static my_bool opt_raw_mode= 0, opt_stop_never= 0; > +static int64 opt_stop_never_slave_server_id= -1; longlong, not int64. Because 1) you've used GET_LL for it, and 2) we generally don't use int64 (it's only used in special cases to mean exactly "signed 64-bit integer"). > static my_bool opt_verify_binlog_checksum= 1; > static ulonglong offset = 0; > static char* host = 0; > @@ -1368,8 +1373,14 @@ static struct my_option my_options[] = > {"read-from-remote-server", 'R', "Read binary logs from a MySQL server.", > &remote_opt, &remote_opt, 0, GET_BOOL, NO_ARG, 0, 0, 0, 0, > 0, 0}, > - {"result-file", 'r', "Direct output to a given file.", 0, 0, 0, GET_STR, > - REQUIRED_ARG, 0, 0, 0, 0, 0, 0}, > + {"raw", OPT_RAW_OUTPUT, "Requires -R. Output raw binlog data instead of SQL " > + "statements and write it to files corresponding to server logs.", What does that mean? "write it to files corresponding to server logs"? Perhaps you could clarify the help text? > + &opt_raw_mode, &opt_raw_mode, 0, GET_BOOL, NO_ARG, 0, 0, 0, 0, > + 0, 0}, > + {"result-file", 'r', "Direct output to a given file. With --raw this is a " > + "prefix for the file names.", > + &result_file_name, &result_file_name, 0, GET_STR, REQUIRED_ARG, > + 0, 0, 0, 0, 0, 0}, > {"server-id", 0, > "Extract only binlog entries created by the server having the given id.", > &server_id, &server_id, 0, GET_ULONG, > @@ -1418,6 +1429,16 @@ static struct my_option my_options[] = > "(you should probably use quotes for your shell to set it properly).", > &stop_datetime_str, &stop_datetime_str, > 0, GET_STR_ALLOC, REQUIRED_ARG, 0, 0, 0, 0, 0, 0}, > + {"stop-never", OPT_STOP_NEVER, "Wait for more data from the server " > + "instead of stopping at the end of the last log. Implicitly sets " > + "--to-last-log but instead of stopping at the end of the last log " > + "it continues to wait till the server disconnects.", I don't know why you needed to say the same thing twice. What about: Wait for more data from the server instead of stopping at the end of the last log. Implies --to-last-log. > + &opt_stop_never, &opt_stop_never, 0, > + GET_BOOL, NO_ARG, 0, 0, 0, 0, 0, 0}, > + {"stop-never-slave-server-id", OPT_WAIT_SERVER_ID, > + "The slave server_id used for --read-from-remote-server --stop-never.", > + &opt_stop_never_slave_server_id, &opt_stop_never_slave_server_id, 0, > + GET_LL, REQUIRED_ARG, -1, -1, 0xFFFFFFFFLL, 0, 0, 0}, GET_LL, really? So, negative server_id's are allowed? Either do it like the existing --server-id option (GET_ULONG, 0 means "not set"), or, if you want to allow 0 as a valid server-id value, you can do, like case OPT_WAIT_SERVER_ID: if (argument == disabled_my_option) opt_stop_never_slave_server_id= -1; break; but really I wouldn't bother and just do like --server-id does. > {"stop-position", OPT_STOP_POSITION, > "Stop reading the binlog at position N. Applies to the last binlog " > "passed on the command line.", > @@ -1701,6 +1718,9 @@ get_one_option(int optid, const struct my_option *opt __attribute__((unused)), > print_version(); > opt_version= 1; > break; > + case OPT_STOP_NEVER: > + to_last_remote_log= 1; > + break; This is wrong, it allows someone to do mysqlbinlog --stop-never --to-last-remote-log=0 and you get incorrect configuration. Alternatively one can do mysqlbinlog --stop-never=1 --stop-never=0 and to_last_remote_log will be magically enabled. Heck, one can even do mysqlbinlog --stop-never=0 and that'll enable to_last_remote_log. The correct approach is to do if (opt_stop_never) to_last_remote_log= TRUE; and only *after* all options are read. Note that in this case you won't need OPT_STOP_NEVER constant either (see my comment earlier in this review) > case '?': > usage(); > opt_version= 1; > @@ -1922,6 +1943,240 @@ static Exit_status check_master_version() > } > > + > + > +static char out_file_name[FN_REFLEN + 1]; > + > +static Exit_status handle_event_raw_mode(PRINT_EVENT_INFO *print_event_info, > + ulong *len, > + const char* logname, uint logname_len) > +{ I'm not reviewing the logic of handle_event_raw_mode, as far as I can see you've copied it from mysqlbinlog in MySQL. Did you use the latest version of mysqlbinlog or the one from the original patch? Use the latest one, it might have bugfixes. > + const char *error_msg; > + const unsigned char *read_pos= mysql->net.read_pos + 1; > + Log_event_type type; > + DBUG_ENTER("handle_event_raw_mode"); > + DBUG_ASSERT(opt_raw_mode && remote_opt); > + > + type= (Log_event_type) read_pos[EVENT_TYPE_OFFSET]; > + > + if (type == HEARTBEAT_LOG_EVENT) > + DBUG_RETURN(OK_CONTINUE); > + > + if (type == ROTATE_EVENT || type == FORMAT_DESCRIPTION_EVENT) > + { > + Log_event *ev; > + if (!(ev= Log_event::read_log_event((const char*) read_pos , > + *len - 1, &error_msg, > + glob_description_event, > + opt_verify_binlog_checksum))) > + { > + error("Could not construct annotate event object: %s", error_msg); may be: "%s", type == ROTATE_EVENT ? "rotate":"annotate" > + DBUG_RETURN(ERROR_STOP); > + } > + /* > + If reading from a remote host, ensure the temp_buf for the > + Log_event class is pointing to the incoming stream. > + */ > + ev->register_temp_buf((char *) read_pos, FALSE); > + > @@ -2000,113 +2264,23 @@ static Exit_status dump_remote_log_entries(PRINT_EVENT_INFO *print_event_info, > break; // end of data > DBUG_PRINT("info",( "len: %lu net->read_pos[5]: %d\n", > len, net->read_pos[5])); > - if (net->read_pos[5] == ANNOTATE_ROWS_EVENT) > + if (opt_raw_mode) > { > - if (!(ev= read_remote_annotate_event(net->read_pos + 1, len - 1, > - &error_msg))) > - { > - error("Could not construct annotate event object: %s", error_msg); > - DBUG_RETURN(ERROR_STOP); > - } > + retval= handle_event_raw_mode(print_event_info, &len, > + logname, logname_len); > } > else > { > - if (!(ev= Log_event::read_log_event((const char*) net->read_pos + 1 , > - len - 1, &error_msg, > - glob_description_event, > - opt_verify_binlog_checksum))) > - { > - error("Could not construct log event object: %s", error_msg); > - DBUG_RETURN(ERROR_STOP); > - } > - /* > - If reading from a remote host, ensure the temp_buf for the > - Log_event class is pointing to the incoming stream. > - */ > - ev->register_temp_buf((char *) net->read_pos + 1, FALSE); > + retval= handle_event_text_mode(print_event_info, &len, > + logname, logname_len, old_off); > } > - > - Log_event_type type= ev->get_type_code(); > - if (glob_description_event->binlog_version >= 3 || > - (type != LOAD_EVENT && type != CREATE_FILE_EVENT)) > + if (retval != OK_CONTINUE) > { > - /* > - If this is a Rotate event, maybe it's the end of the requested binlog; > - in this case we are done (stop transfer). > - This is suitable for binlogs, not relay logs (but for now we don't read > - relay logs remotely because the server is not able to do that). If one > - day we read relay logs remotely, then we will have a problem with the > - detection below: relay logs contain Rotate events which are about the > - binlogs, so which would trigger the end-detection below. > - */ > - if (type == ROTATE_EVENT) > - { > - Rotate_log_event *rev= (Rotate_log_event *)ev; > - /* > - If this is a fake Rotate event, and not about our log, we can stop > - transfer. If this a real Rotate event (so it's not about our log, > - it's in our log describing the next log), we print it (because it's > - part of our log) and then we will stop when we receive the fake one > - soon. > - */ > - if (rev->when == 0) > - { > - if (!to_last_remote_log) > - { > - if ((rev->ident_len != logname_len) || > - memcmp(rev->new_log_ident, logname, logname_len)) > - { > - DBUG_RETURN(OK_CONTINUE); > - } > - /* > - Otherwise, this is a fake Rotate for our log, at the very > - beginning for sure. Skip it, because it was not in the original > - log. If we are running with to_last_remote_log, we print it, > - because it serves as a useful marker between binlogs then. > - */ > - continue; > - } > - len= 1; // fake Rotate, so don't increment old_off > - } > - } > - else if (type == FORMAT_DESCRIPTION_EVENT) > - { > - /* > - This could be an fake Format_description_log_event that server > - (5.0+) automatically sends to a slave on connect, before sending > - a first event at the requested position. If this is the case, > - don't increment old_off. Real Format_description_log_event always > - starts from BIN_LOG_HEADER_SIZE position. > - */ > - if (old_off != BIN_LOG_HEADER_SIZE) > - len= 1; // fake event, don't increment old_off > - } > - Exit_status retval= process_event(print_event_info, ev, old_off, logname); > - if (retval != OK_CONTINUE) > - DBUG_RETURN(retval); > + if (retval == OK_EOF) > + break; > + DBUG_RETURN(retval); > } > - else > - { > - Load_log_event *le= (Load_log_event*)ev; > - const char *old_fname= le->fname; > - uint old_len= le->fname_len; > - File file; > - Exit_status retval; > > - if ((file= load_processor.prepare_new_file_for_old_format(le,fname)) < 0) > - DBUG_RETURN(ERROR_STOP); > - > - retval= process_event(print_event_info, ev, old_off, logname); > - if (retval != OK_CONTINUE) > - { > - my_close(file,MYF(MY_WME)); > - DBUG_RETURN(retval); > - } > - retval= load_processor.load_old_format_file(net,old_fname,old_len,file); > - my_close(file,MYF(MY_WME)); > - if (retval != OK_CONTINUE) > - DBUG_RETURN(retval); > - } Hmm, when you moved all that code above into handle_event_text_mode(), you seem to have changed the behavior for to_last_remote_log. Was (comments removed for brevity): if (!to_last_remote_log) { if ((rev->ident_len != logname_len) || memcmp(rev->new_log_ident, logname, logname_len)) { DBUG_RETURN(OK_CONTINUE); } continue; } Now instead of 'continue' you return OK_CONTINUE from handle_event_text_mode() and it does not skip the code below (after the comment Let's adjust), like the old 'continue' did. > /* > Let's adjust offset for remote log as for local log to produce > similar text and to have --stop-position to work identically. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0