- developers - lists.mariadb.org

Re: [Maria-developers] GTID and removing binary logs
by Kristian Nielsen 08 Aug '13

08 Aug '13

Elena Stepanova <elenst(a)montyprogram.com> writes: > Reading recent Pavel Ivanov's reports (the last one is MDEV-4820, but > I think there were some others which you've already closed as fixed), > I started wondering if I conceptually misunderstood something > before. From our previous discussions I made a conclusion that > removing *all* binary logs before trying to replicate from the server > is very wrong and against the whole idea of GTID. Is it not so? If > not, it's definitely an area which didn't undergo any testing from me, > except for my very first clumsy attempts to get familiar with GTID, so > I need to fill the gap. Well, we _do_ want to support running a slave with --log-slave-updates=0, and then making that slave into a master. Indeed, you tested that early and it was horribly broken. However, my intention is that this should now be supported (and thus can be tested). There are MTR testcases for this. The reason I mention this is that the case of --log-slave-updates=0 is actually quite similar (from the server's point of view) to manually deleting the logs. So I do also intend to support removing binlogs as Pavel wants to do. The main problem with doing this (deleting binlogs or using --log-slave-updates=0) is that it makes it harder to detect certain user errors, because the information to know that it is an error is missing. I suppose the limitations should be pretty obvious: If user deletes binlogs on a server, then that server, acting as a master, can not replicate to slaves starting from an event that was deleted. So as long as the user does not try to do that, things should be fine. I think the main problems come if the user makes a mistake in this respect, and the server fails to detect the error. For example, suppose that server A is a slave, replicates up to position 0-2-10. Then it becomes a master, generates events up to 0-1-20. Then user deletes the binlogs on A, and tries to have server B replicate from A starting at position 0-2-10. In this case, server A will allow B to connect, effectively loosing the deleted events 0-1-11 .. 0-1-20. I do not see any way to avoid this. Server A has no way to know that those events ever existed, as the user deliberately deleted all information about them. (In fact the user might be doing this deliberately, in case the events were wrongly created and should be removed from the history). A workaround in this example is that the user sets @@gtid_slave_pos explicitly to 0-1-20 after deleting the logs, thus preserving the needed information. So in summary: Yes, we try to support deleting binlogs, however there is some responsibility on the part of the user to not delete information that they actually need. I think that is rather reasonable. It is how DELETE and SELECT work, as well :-) - Kristian.

1 0

Re: [Maria-developers] [Commits] Rev 3772: MDEV-4645: Incorrect reads of frozen binlog events; FDE corrupted in relay log in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-4548/
by Jeremy Cole 08 Aug '13

08 Aug '13

Sanja, Re: https://mariadb.atlassian.net/browse/MDEV-4645 Re: http://lists.askmonty.org/pipermail/commits/2013-July/005093.html I saw your commit on the commits list (sorry, wasn't on the list before the mail went out, so I can't reply directly to that message). A couple of points related to the commit: - You seem to have an error in the get_header_len, as it's implemented only in the base class, and you've left functions with the correct signature for it but the wrong names in the two frozen classes (they were left named has_fixed_minimal_header). This would mean the change is completely broken. :) - The change to get_header_len I think is in general fine, although it does alter the point of the whole thing -- there is again no way to exactly identify which events have frozen headers, programmatically (i.e. you can't differentiate them from events who just "happen" to have header_len = LOG_EVENT_MINIMAL_HEADER_LEN). I think that doesn't matter for this patch, but does defeat the point of what I was trying to add. - I don't really understand why you've made the hex printing code so complex and completely unreadable (IMHO). This is not performance-sensitive code and in my opinion should favor readability over performance. All you seem to have saved in this change is to avoid printing some static formatting characters ("#", "|", spaces, etc.) inside the loop. However, I can hardly even figure out what it's supposed to be doing now. - Additionally, you've changed the output slightly -- normally the ASCII character section prints its ending "|" immediately after the last character; it seems now to be fixed position (leaving extra spaces before "|". This differs from the output of hexdump, and it somewhat ambiguous/confusing. - You've mixed tabs and spaces. :( Regards, Jeremy

2 8

[Maria-developers] RFC - temporary path and SSD/HDD
by Roberto Spadim 07 Aug '13

07 Aug '13

Hi guys I have some server running with bcache and some in test running flash cache and others linux ssd cache solution I was thinking about how to optimize the temporary tables of mysql/mariadb... could we implement something like: Temporary Slow/Big Path = /tmp/hdd Temporary Fast/Small Path = /tmp/ssd Temporary Fast Max Size = 10MB When we start using temporary tables (file sort for example) instead of write to a hdd temporary disk, use a ssd temporary disk, if table get bigger than 10MB, copy the file to hdd drive, and remove from ssd drive, and continue writing to hdd I think with this i could optimize the temporary table use Any other idea about this kind of optimization? -- Roberto Spadim

1 0

Re: [Maria-developers] [Commits] Rev 3671: MDEV-4811 Assertion `offset < 0x1f' fails in type_and_offset_store on COLUMN_ADD in file:///home/bell/maria/bzr/work-maria-5.3-MDEV-4811/
by Sergei Petrunia 07 Aug '13

07 Aug '13

Hi Sanja, Ok to push. On Thu, Aug 01, 2013 at 11:46:14AM +0300, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.3-MDEV-4811/ > > ------------------------------------------------------------ > revno: 3671 > revision-id: sanja(a)montyprogram.com-20130801084611-cu3wpoazd197g41w > parent: sergii(a)pisem.net-20130715163225-6ch6x34lsufode3d > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.3-MDEV-4811 > timestamp: Thu 2013-08-01 11:46:11 +0300 > message: > MDEV-4811 Assertion `offset < 0x1f' fails in type_and_offset_store on COLUMN_ADD > MDEV-4812 Valgrind warnings (Invalid write) in dynamic_column_update_many on COLUMN_ADD > > Fixed problem of working on wrong data (do not allow offset to out of string length). > === modified file 'mysql-test/r/dyncol.result' > --- a/mysql-test/r/dyncol.result 2013-03-26 11:07:46 +0000 > +++ b/mysql-test/r/dyncol.result 2013-08-01 08:46:11 +0000 > @@ -1404,5 +1404,26 @@ v1 CREATE ALGORITHM=UNDEFINED DEFINER=`r > drop view v1; > drop table t1; > # > +# MDEV-4811: Assertion `offset < 0x1f' fails in type_and_offset_store > +# on COLUMN_ADD > +# > +CREATE TABLE t1 (dyn TINYBLOB) ENGINE=MyISAM; > +INSERT INTO t1 SET dyn = COLUMN_CREATE( 40, REPEAT('a', 233), 4, REPEAT('b', 322) ); > +Warnings: > +Warning 1265 Data truncated for column 'dyn' at row 1 > +SELECT COLUMN_ADD( dyn, 6, REPEAT('x',80), 4, REPEAT('y',215) AS INTEGER ) FROM t1; > +ERROR HY000: Encountered illegal format of dynamic column string > +DROP table t1; > +# > +# MDEV-4812: Valgrind warnings (Invalid write) in > +# dynamic_column_update_many on COLUMN_ADD > +# > +CREATE TABLE t1 (dyncol TINYBLOB) ENGINE=MyISAM; > +INSERT INTO t1 SET dyncol = COLUMN_CREATE( 7, REPEAT('k',487), 209, REPEAT('x',464) ); > +Warnings: > +Warning 1265 Data truncated for column 'dyncol' at row 1 > +SELECT COLUMN_ADD( dyncol, 7, '22:22:22', 8, REPEAT('x',270) AS CHAR ) FROM t1; > +DROP table t1; > +# > # end of 5.3 tests > # > > === modified file 'mysql-test/t/dyncol.test' > --- a/mysql-test/t/dyncol.test 2013-03-26 11:07:46 +0000 > +++ b/mysql-test/t/dyncol.test 2013-08-01 08:46:11 +0000 > @@ -600,6 +600,29 @@ drop view v1; > drop table t1; > > --echo # > +--echo # MDEV-4811: Assertion `offset < 0x1f' fails in type_and_offset_store > +--echo # on COLUMN_ADD > +--echo # > + > +CREATE TABLE t1 (dyn TINYBLOB) ENGINE=MyISAM; > +INSERT INTO t1 SET dyn = COLUMN_CREATE( 40, REPEAT('a', 233), 4, REPEAT('b', 322) ); > +--error ER_DYN_COL_WRONG_FORMAT > +SELECT COLUMN_ADD( dyn, 6, REPEAT('x',80), 4, REPEAT('y',215) AS INTEGER ) FROM t1; > + > +DROP table t1; > + > +--echo # > +--echo # MDEV-4812: Valgrind warnings (Invalid write) in > +--echo # dynamic_column_update_many on COLUMN_ADD > +--echo # > +CREATE TABLE t1 (dyncol TINYBLOB) ENGINE=MyISAM; > + > +INSERT INTO t1 SET dyncol = COLUMN_CREATE( 7, REPEAT('k',487), 209, REPEAT('x',464) ); > +--error 0,ER_DYN_COL_WRONG_FORMAT > +SELECT COLUMN_ADD( dyncol, 7, '22:22:22', 8, REPEAT('x',270) AS CHAR ) FROM t1; > +DROP table t1; > + > +--echo # > --echo # end of 5.3 tests > --echo # > > > === modified file 'mysys/ma_dyncol.c' > --- a/mysys/ma_dyncol.c 2011-10-18 10:44:12 +0000 > +++ b/mysys/ma_dyncol.c 2013-08-01 08:46:11 +0000 > @@ -1228,13 +1228,14 @@ dynamic_column_create(DYNAMIC_COLUMN *st > @param header_end Pointer to the header end > @param offset_size Size of offset field in bytes > @param last_offset Size of the data segment > + @param error Set in case of error > > @return number of bytes > */ > > static size_t get_length_interval(uchar *entry, uchar *entry_next, > uchar *header_end, size_t offset_size, > - size_t last_offset) > + size_t last_offset, my_bool *error) > { > size_t offset, offset_next; > DYNAMIC_COLUMN_TYPE type, type_next; > @@ -1242,8 +1243,12 @@ static size_t get_length_interval(uchar > > type_and_offset_read(&type, &offset, entry, offset_size); > if (entry_next >= header_end) > + { > + *error= 0; > return (last_offset - offset); > + } > type_and_offset_read(&type_next, &offset_next, entry_next, offset_size); > + *error= (offset_next > last_offset); > return (offset_next - offset); > } > > @@ -1255,17 +1260,18 @@ static size_t get_length_interval(uchar > @param header_end Pointer to the header end > @param offset_size Size of offset field in bytes > @param last_offset Size of the data segment > + @param error Set in case of error > > @return number of bytes > */ > > static size_t get_length(uchar *entry, uchar *header_end, > size_t offset_size, > - size_t last_offset) > + size_t last_offset, my_bool *error) > { > return get_length_interval(entry, > entry + offset_size + COLUMN_NUMBER_SIZE, > - header_end, offset_size, last_offset); > + header_end, offset_size, last_offset, error); > } > > > @@ -1304,6 +1310,7 @@ find_column(DYNAMIC_COLUMN_TYPE *type, u > uchar *entry; > size_t offset, total_data, header_size, entry_size; > uchar key[2+4]; > + my_bool error; > > if (!entry_pos) > entry_pos= &entry; > @@ -1329,12 +1336,12 @@ find_column(DYNAMIC_COLUMN_TYPE *type, u > return 1; > *data= header + header_size + offset; > *length= get_length(entry, header + header_size, offset_size, > - total_data); > + total_data, &error); > /* > Check that the found data is withing the ranges. This can happen if > we get data with wrong offsets. > */ > - if ((long) *length < 0 || offset + *length > total_data) > + if (error || (long) *length < 0 || offset + *length > total_data) > return 1; > > *entry_pos= entry; > @@ -1837,12 +1844,13 @@ dynamic_column_update_many(DYNAMIC_COLUM > entry_size, column_count, &entry)) > { > size_t entry_data_size; > + my_bool error; > > /* Data existed; We have to replace or delete it */ > > entry_data_size= get_length(entry, header_end, > - offset_size, max_offset); > - if ((long) entry_data_size < 0) > + offset_size, max_offset, &error); > + if (error || (long) entry_data_size < 0) > { > rc= ER_DYNCOL_FORMAT; > goto end; > @@ -2038,12 +2046,13 @@ dynamic_column_update_many(DYNAMIC_COLUM > /* copy first the data that was not replaced in original packed data */ > if (start < end) > { > + my_bool error; > /* Add old data last in 'tmp' */ > size_t data_size= > get_length_interval(header_base + start * entry_size, > header_base + end * entry_size, > - header_end, offset_size, max_offset); > - if ((long) data_size < 0 || > + header_end, offset_size, max_offset, &error); > + if (error || (long) data_size < 0 || > data_size > max_offset - first_offset) > { > dynamic_column_column_free(&tmp); > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 3797: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg in file:///data0/psergey/dev2/10.0-serg/
by Kristian Nielsen 07 Aug '13

07 Aug '13

Sergey Petrunya <psergey(a)askmonty.org> writes: > revision-id: psergey(a)askmonty.org-20130802141209-4dqfvx2db8acxwbl > message: > MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg > Temorary fix for a number of replication tests (rpl.rpl_temp_table_mix_row > rpl.rpl_trunc_temp rpl.rpl_current_user rpl.rpl_gtid_master_promote): The patch is not ok to push. We should not introduce a special flag just for the table gtid_slave_pos. Instead of setting table->no_replicate in the first place in rpl_slave_state::truncate_state_table() and rpl_slave_state::record_gtid(), we can clear the OPTION_BIN_LOG option. I checked MySQL 5.6 code and this is what they do for their similar "crash-safe replication" tables. So remove the two statements "table->no_replicate= 1" in rpl_gtid.cc and replace with clear of OPTION_BIN_LOG in thd->variables.option_bits. Then table->no_replicate is not touched and the new logic in THD::decide_logging_format() does not trigger, so the problem should be solved. In rpl_slave_state::truncate_state_table() we can use tmp_disable_binlog() and reenable_binlog() I think. In record_gtid() it is probably better to combine the clearing of OPTION_BIN_LOG with the existing save/restore of variables.option_bits. > The question of what should be done when a user issues a statement that > explicitly modifies mysql.gtid_slave_pos table remains open. I do not think we need to do anything special for this case. User explicitly modifying the table should be treated no different than any other table. Hope this helps, - Kristian. > === modified file 'sql/rpl_gtid.cc' > --- a/sql/rpl_gtid.cc 2013-06-21 09:53:46 +0000 > +++ b/sql/rpl_gtid.cc 2013-08-02 14:12:09 +0000 > @@ -210,6 +210,7 @@ rpl_slave_state::truncate_state_table(TH > { > table= tlist.table; > table->no_replicate= 1; > + table->s->is_gtid_slave_pos= TRUE; // TEMPORARY CODE > err= table->file->ha_truncate(); > > if (err) > @@ -346,6 +347,7 @@ rpl_slave_state::record_gtid(THD *thd, c > goto end; > > table->no_replicate= 1; > + table->s->is_gtid_slave_pos= TRUE; // TEMPORARY CODE > if (!in_transaction) > thd->variables.option_bits&= > ~(ulonglong)(OPTION_NOT_AUTOCOMMIT|OPTION_BEGIN); > > === modified file 'sql/sql_class.cc' > --- a/sql/sql_class.cc 2013-07-24 10:43:57 +0000 > +++ b/sql/sql_class.cc 2013-08-02 14:12:09 +0000 > @@ -5001,7 +5001,7 @@ int THD::decide_logging_format(TABLE_LIS > DBUG_PRINT("info", ("table: %s; ha_table_flags: 0x%llx", > table->table_name, flags)); > > - if (table->table->no_replicate) > + if (table->table->no_replicate && !table->table->s->is_gtid_slave_pos) > { > /* > The statement uses a table that is not replicated. > > === modified file 'sql/table.cc' > --- a/sql/table.cc 2013-07-21 14:43:42 +0000 > +++ b/sql/table.cc 2013-08-02 14:12:09 +0000 > @@ -315,6 +315,8 @@ TABLE_SHARE *alloc_table_share(const cha > strmov(share->path.str, path); > share->normalized_path.str= share->path.str; > share->normalized_path.length= path_length; > + /* TEMPORARY FIX: if true, this means this is mysql.gtid_slave_pos table */ > + share->is_gtid_slave_pos= FALSE; > share->table_category= get_table_category(& share->db, & share->table_name); > share->set_refresh_version(); > share->open_errno= ENOENT; > > === modified file 'sql/table.h' > --- a/sql/table.h 2013-07-21 14:39:19 +0000 > +++ b/sql/table.h 2013-08-02 14:12:09 +0000 > @@ -644,6 +644,8 @@ struct TABLE_SHARE > LEX_STRING normalized_path; /* unpack_filename(path) */ > LEX_STRING connect_string; > > + bool is_gtid_slave_pos; > + > /* > Set of keys in use, implemented as a Bitmap. > Excludes keys disabled by ALTER TABLE ... DISABLE KEYS. > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

[Maria-developers] COT() function
by Ian Gilfillan 03 Aug '13

03 Aug '13

Hi SELECT COT(0) returns: ERROR 1690 (22003): DOUBLE value is out of range in 'cot(0)' in both MariaDB 10 and 5.5, but in MySQL 5.1 it returns NULL. I can't find a changelog reference to this, but I see it's still documented as returning NULL in MySQL 5.5 (I don't have this to test on). Is this a MariaDB-specific change? When did this change in behaviour happen? thanks, ian

3 5

[Maria-developers] Please review: [Commits] Rev 3797: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg in file:///data0/psergey/dev2/10.0-serg/
by Sergei Petrunia 02 Aug '13

02 Aug '13

Hi Kristian, In order to get rid of test failures of 10.0-serg, I have pushed the below patch. It seems to have the right effect, but I have no confidence about this patch being achitecturally correct, etc. Could you please review this and/or make another fix for the problem? ----- Forwarded message from Sergey Petrunya <psergey(a)askmonty.org> ----- From: Sergey Petrunya <psergey(a)askmonty.org> To: commits(a)mariadb.org X-Mailer: mail (GNU Mailutils 2.2) Date: Fri, 2 Aug 2013 18:12:11 +0400 (MSK) Subject: [Commits] Rev 3797: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg in file:///data0/psergey/dev2/10.0-serg/ At file:///data0/psergey/dev2/10.0-serg/ ------------------------------------------------------------ revno: 3797 revision-id: psergey(a)askmonty.org-20130802141209-4dqfvx2db8acxwbl parent: svoj(a)mariadb.org-20130729140849-dciz5ffq25ciip6q committer: Sergey Petrunya <psergey(a)askmonty.org> branch nick: 10.0-serg timestamp: Fri 2013-08-02 18:12:09 +0400 message: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg Temorary fix for a number of replication tests (rpl.rpl_temp_table_mix_row rpl.rpl_trunc_temp rpl.rpl_current_user rpl.rpl_gtid_master_promote): - THD::decide_logging_format() should not assume that mysql.gtid_slave_pos is a non-replicated table. This used to cause unintended behavior for COMMIT statement: replication would switch to row-based, etc. The question of what should be done when a user issues a statement that explicitly modifies mysql.gtid_slave_pos table remains open. === modified file 'sql/rpl_gtid.cc' --- a/sql/rpl_gtid.cc 2013-06-21 09:53:46 +0000 +++ b/sql/rpl_gtid.cc 2013-08-02 14:12:09 +0000 @@ -210,6 +210,7 @@ rpl_slave_state::truncate_state_table(TH { table= tlist.table; table->no_replicate= 1; + table->s->is_gtid_slave_pos= TRUE; // TEMPORARY CODE err= table->file->ha_truncate(); if (err) @@ -346,6 +347,7 @@ rpl_slave_state::record_gtid(THD *thd, c goto end; table->no_replicate= 1; + table->s->is_gtid_slave_pos= TRUE; // TEMPORARY CODE if (!in_transaction) thd->variables.option_bits&= ~(ulonglong)(OPTION_NOT_AUTOCOMMIT|OPTION_BEGIN); === modified file 'sql/sql_class.cc' --- a/sql/sql_class.cc 2013-07-24 10:43:57 +0000 +++ b/sql/sql_class.cc 2013-08-02 14:12:09 +0000 @@ -5001,7 +5001,7 @@ int THD::decide_logging_format(TABLE_LIS DBUG_PRINT("info", ("table: %s; ha_table_flags: 0x%llx", table->table_name, flags)); - if (table->table->no_replicate) + if (table->table->no_replicate && !table->table->s->is_gtid_slave_pos) { /* The statement uses a table that is not replicated. === modified file 'sql/table.cc' --- a/sql/table.cc 2013-07-21 14:43:42 +0000 +++ b/sql/table.cc 2013-08-02 14:12:09 +0000 @@ -315,6 +315,8 @@ TABLE_SHARE *alloc_table_share(const cha strmov(share->path.str, path); share->normalized_path.str= share->path.str; share->normalized_path.length= path_length; + /* TEMPORARY FIX: if true, this means this is mysql.gtid_slave_pos table */ + share->is_gtid_slave_pos= FALSE; share->table_category= get_table_category(& share->db, & share->table_name); share->set_refresh_version(); share->open_errno= ENOENT; === modified file 'sql/table.h' --- a/sql/table.h 2013-07-21 14:39:19 +0000 +++ b/sql/table.h 2013-08-02 14:12:09 +0000 @@ -644,6 +644,8 @@ struct TABLE_SHARE LEX_STRING normalized_path; /* unpack_filename(path) */ LEX_STRING connect_string; + bool is_gtid_slave_pos; + /* Set of keys in use, implemented as a Bitmap. Excludes keys disabled by ALTER TABLE ... DISABLE KEYS. _______________________________________________ commits mailing list commits(a)mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ----- End forwarded message ----- -- BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 3215: MDEV-4823: Server crashes in Item_func_not::fix_fields on creating a table with a virtual column using NOT in file:///home/bell/maria/bzr/work-maria-5.2-MDEV-4823/
by Sergei Petrunia 31 Jul '13

31 Jul '13

Hi Sanja, On Tue, Jul 30, 2013 at 11:00:59AM +0300, sanja(a)montyprogram.com wrote: > At file:///home/bell/maria/bzr/work-maria-5.2-MDEV-4823/ > > ------------------------------------------------------------ > revno: 3215 > revision-id: sanja(a)montyprogram.com-20130730080057-ylgl6h11l2b3yflc > parent: wlad(a)montyprogram.com-20130709202457-6n9syq59jdd2sy3b > committer: sanja(a)montyprogram.com > branch nick: work-maria-5.2-MDEV-4823 > timestamp: Tue 2013-07-30 11:00:57 +0300 > message: > MDEV-4823: Server crashes in Item_func_not::fix_fields on creating a table with a virtual column using NOT > > fix_field() call protocol was brocken (zero pointer passed as link to item which is possible only if you are sure that there can not be Items which transforms). ... > === modified file 'sql/table.cc' > --- a/sql/table.cc 2013-01-16 00:46:27 +0000 > +++ b/sql/table.cc 2013-07-30 08:00:57 +0000 > @@ -1812,7 +1812,7 @@ bool fix_vcol_expr(THD *thd, > bool result= TRUE; > TABLE_LIST tables; > TABLE_LIST *save_table_list, *save_first_table, *save_last_table; > - int error; > + int error= 0; > Name_resolution_context *context; > const char *save_where; > char* db_name; > @@ -1860,7 +1860,13 @@ bool fix_vcol_expr(THD *thd, > save_use_only_table_context= thd->lex->use_only_table_context; > thd->lex->use_only_table_context= TRUE; > /* Fix fields referenced to by the virtual column function */ > - error= func_expr->fix_fields(thd, (Item**)0); > + if (!func_expr->fixed) > + error= func_expr->fix_fields(thd, (Item**)&vcol_info->expr_item); There is no need to use (Item**) cast, please remove it. Ok to push after that. > + > + /* fix_fields could change the expression */ > + func_expr= vcol_info->expr_item; > + /* Number of columns will be checked later */ > + > /* Restore the original context*/ > thd->lex->use_only_table_context= save_use_only_table_context; > context->table_list= save_table_list; > BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] Plugin security
by Leif Walsh 30 Jul '13

30 Jul '13

Hi, I'm working on adding a plugin API (not exactly a storage engine API, rather an extension one) to TokuMX[1] and I'm looking for advice on security. The basic idea is fairly simple: a plugin is a shared library (we're only targeting Linux right now, by the way) that defines a symbol to bootstrap the loading of additional functionality. We have an admin-only command that calls dlopen and dlsym to load the plugin. I haven't read any of the MariaDB plugin code yet, so pointers to where to start reading would be appreciated. Apart from that, I'm just looking for any advice from you all about what to watch out for. My concerns break down into two main areas: 1. When loading a single plugin, what should I watch out for? The command itself is admin-only so calling it is protected, but what about an attacker that drops a malicious plugin in a directory earlier on the load path? What should I check about the permissions/owner of the library file and the directory in which it lives? Is erroring out on world-writable libraries enough? If my process is setuid, should I be more careful? What does Maria do here? 2. About plugin persistence/autoloading: I understand MariaDB has a system table that tracks which plugins are installed and automatically loads those on startup. I believe I can do the same thing in TokuMX and I can restrict access to that collection to the admin user. What does MariaDB store in that table and how does it use it? I could imagine storing the checksum of the installed plugin in the system table and verifying it before loading the plugin, but this seems rather draconian and it might make plugin upgrades too difficult. Does MariaDB verify the permissions of the data files that store this system table? I could imagine an attack where you would replace this system table with one that includes instructions to load your malicious plugin, while the server is offline. Again, how does MariaDB solve these problems? Another option is to autoload all libraries in some directory, and to just be very careful about the permissions of that directory, but this seems very hard to get totally right so I'm leaning away from it. [1]: http://www.tokutek.com/products/tokumx-for-mongodb -- Cheers, Leif

3 5

[Maria-developers] Master slave
by Richard Couture 30 Jul '13

30 Jul '13

Is it possible to set up replication in such a manner as to permit writing records to either a master or a slave replica? We want to set up a fail safe replica that can easily take over when our connection to the main replica fails, which, unfortunately, is fairly often. I read a document, some time ago which mentioned several types of replication, i.e.: by record, by table ... and the pitfalls, like IDs not necessarily matching... which confused me more than anything else... Can someone point me to some good documentation to enable me to pick the correct type of replication that I need to accomplish my task?? Thanks Richard -- LinuxCabal Asociación Civil Ing. Richard Couture Novell CNE, ECNE, MCNE HP/Compaq ASE Tel.: (+52) (333) 145-2638 Cel.: (+52) (044) 333 377-7505 Cel.: (+52) (044) 333 377-7506 Web: http://www.LinuxCabal.org E-Mail: rrc(a)linuxcabal.org Hosted en la nube Cloud Sigma - www.CloudSigma.com AVISO DE CONFIDENCIALIDAD: Este correo electrónico, incluyendo en su caso, los archivos adjuntos al mismo, pueden contener información de carácter confidencial y/o privilegiada, y se envían a la atención única y exclusivamente de la persona y/o entidad a quien va dirigido. La copia, revisión, uso, revelación y/o distribución de dicha información confidencial sin la autorización por escrito de LinuxCabal está prohibida. Si usted no es el destinatario a quien se dirige el presente correo, favor de contactar al remitente respondiendo al presente correo y eliminar el correo original incluyendo sus archivos, así como cualesquiera copia del mismo. Mediante la recepción del presente correo usted reconoce y acepta que en caso de incumplimiento de su parte y/o de sus representantes a los términos antes mencionados, LinuxCabal tendrá derecho a los daños y perjuicios que esto le cause.

1 0