- developers - lists.mariadb.org

Re: [Maria-developers] b0d21b7: MDEV-14567 Include full name of object in message about incorrect value for column.
by Sergei Golubchik 06 Nov '18

06 Nov '18

Hi, Alexey! On Nov 06, Alexey Botchkov wrote: > > That's why I asked what temporary tables have in table->s->db and > > in table->s->table_name. What do they have there? > > 'Persistent' temporary tables (those created by CREATE TEMPORARY > TABLE) have their database/name there. > Auxiliary temporary tables created to execute queries like SELECT have > 'normal' db value and soumething like #sql_1234 as a table name. But that's fine to show, right? No NULL, no garbage. No need to treat them specially. By the way, can this error ever happen for internal temporary tables? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] b0d21b7: MDEV-14567 Include full name of object in message about incorrect value for column.
by Sergei Golubchik 06 Nov '18

06 Nov '18

Hi, Alexey! On Nov 06, Alexey Botchkov wrote: > > >> + long_field_name(buf, sizeof(buf), table->s, field_name), > >Better change the error message to be > > Incorrect decimal value: '%s' for column %`s.%`s.%`s at row %d > > and use like > > - field_name, > > + table->s->db.str, table->s->table_name.str, field_name, > > Don't think it is better. > There are temporary tables and just Item's that launch that error. So > the 'db' and 'table' do not always defined properly. > The long_field_name() i added handles the temporary table case. Yes, I've noticed you had a specia case for temporary tables. That's why I asked what temporary tables have in table->s->db and in table->s->table_name. What do they have there? Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] dc9f113111e: MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX
by Sergei Golubchik 05 Nov '18

05 Nov '18

Hi, Thirunarayanan! On Nov 05, Thirunarayanan Balathandayuthapani wrote: > revision-id: dc9f113111ee4daf3964db938ef3ddd82c777328 (mariadb-10.0.37-6-gdc9f113111e) > parent(s): 38b3e52c3c40b35339b1d18c09053be416a93420 > author: Thirunarayanan Balathandayuthapani <thiru(a)mariadb.com> > committer: Thirunarayanan Balathandayuthapani <thiru(a)mariadb.com> > timestamp: 2018-11-01 21:24:03 +0530 > message: > > MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX > if unique index nominated as PK Subject line in git commits is always one line. Try to prefer the format as of MDEV-17376 Server fails to set ADD_PK_INDEX, DROP_PK_INDEX if unique index nominated as PK that is, MDEV-number, one space, MDEV summary verbatim, all on one line. This way it'll look good in `git log --oneline` and one can search for a bug description (and new lines won't cause the search to fail). > - Server sets the flag ADD_PK_INDEX, DROP_PK_INDEX if the unique key > nominated as Primary key. this isn't a very helpful comment, just a rephrased commit title :) Up to you, of course, it doesn't hurt. But generally, if you feel the fix it kind of obvious and you cannot come up with anything to put into commit comment body, just don't put there anything at all. > > diff --git a/mysql-test/suite/innodb/t/alter_candidate_key.test b/mysql-test/suite/innodb/t/alter_candidate_key.test > --- /dev/null > +++ b/mysql-test/suite/innodb/t/alter_candidate_key.test > @@ -0,0 +1,47 @@ > +--source include/have_innodb.inc > +--source include/have_debug.inc > +--source include/have_debug_sync.inc > + > +CREATE TABLE t1 (f1 INT NOT NULL, f2 INT NOT NULL, > + UNIQUE KEY uidx2(f1,f2), > + UNIQUE KEY uidx1(f2) > +) ENGINE=InnoDB; > + > +SET DEBUG_SYNC = 'innodb_inplace_alter_table_enter SIGNAL conc_dml WAIT_FOR go_ahead'; > +INSERT INTO t1 VALUES(1,1); > +--send > +alter table t1 change column f1 f11 int, algorithm=inplace; > +connect (con1,localhost,root,,); > +SET DEBUG_SYNC = 'now WAIT_FOR conc_dml'; > +DELETE FROM t1; > +SET DEBUG_SYNC = 'now SIGNAL go_ahead'; > +connection default; > +reap; > +CHECK TABLE t1; > +DROP TABLE t1; Could you explain the test case, please? What's going on here? I don't understand what you're fixing and what I'm reviewing, sorry :( Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 5403baabc7e: MDEV-16849 Extending indexed VARCHAR column should be instantaneous
by Sergei Golubchik 05 Nov '18

05 Nov '18

Hi, Thirunarayanan! On Nov 05, Thirunarayanan Balathandayuthapani wrote: > revision-id: 5403baabc7ef87e301964434e3670ded06af0802 (mariadb-10.2.18-40-g5403baabc7e) > parent(s): ab1ce2204e959bea596817494e932754ab5cbe88 > author: Thirunarayanan Balathandayuthapani <thiru(a)mariadb.com> > committer: Thirunarayanan Balathandayuthapani <thiru(a)mariadb.com> > timestamp: 2018-10-26 16:49:08 +0530 > message: > > MDEV-16849 Extending indexed VARCHAR column should be instantaneous > > Analysis: > ======== > Increasing the length of the indexed varchar column is not an instant operation for > innodb. > > Fix: > === > - Introduce the new handler flag 'Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH' to > indicate the index length differs due to change of column length changes. > > - InnoDB makes the ALTER_COLUMN_INDEX_LENGTH flag as instant operation. > > This is a port of Mysql fix. > > diff --git a/sql/handler.cc b/sql/handler.cc > index da41daf2440..b1fa53fb145 100644 > --- a/sql/handler.cc > +++ b/sql/handler.cc > @@ -4253,7 +4253,8 @@ handler::check_if_supported_inplace_alter(TABLE *altered_table, > Alter_inplace_info::CHANGE_CREATE_OPTION | > Alter_inplace_info::ALTER_PARTITIONED | > Alter_inplace_info::ALTER_VIRTUAL_GCOL_EXPR | > - Alter_inplace_info::ALTER_RENAME; > + Alter_inplace_info::ALTER_RENAME | > + Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH; You sure? It means that any engine by default can do ALTER_COLUMN_INDEX_LENGTH inplace, unless some other check in the engine disallows it. I'd rather not enable it for all engine, so better remove it. InnoDB has his own check inside ha_innobase::check_if_supported_inplace_alter() anyway. > /* Is there at least one operation that requires copy algorithm? */ > if (ha_alter_info->handler_flags & ~inplace_offline_operations) > diff --git a/sql/handler.h b/sql/handler.h > index ed2ef822c88..f2250699cfb 100644 > --- a/sql/handler.h > +++ b/sql/handler.h > @@ -1994,6 +1994,11 @@ class Alter_inplace_info > > static const HA_ALTER_FLAGS ALTER_DROP_CHECK_CONSTRAINT= 1ULL << 40; > > + /** > + Change in index length such that it doesn't require index rebuild. > + */ > + static const HA_ALTER_FLAGS ALTER_COLUMN_INDEX_LENGTH= 1ULL << 41; > + > /** > Create options (like MAX_ROWS) for the new version of table. > > diff --git a/sql/sql_table.cc b/sql/sql_table.cc > index 02780e7d1e0..94d35c99d0a 100644 > --- a/sql/sql_table.cc > +++ b/sql/sql_table.cc > @@ -6687,18 +6687,27 @@ static bool fill_alter_inplace_info(THD *thd, > key_part < end; > key_part++, new_part++) > { > + new_field= get_field_by_index(alter_info, new_part->fieldnr); > /* > + If there is a change in index length due to column expansion > + like varchar(X) changed to varchar(X + N) and has a compatible > + packed data representation, we mark it for fast/INPLACE change > + in index definition. InnoDB supports INPLACE for this cases > + > Key definition has changed if we are using a different field or > - if the used key part length is different. It makes sense to > - check lengths first as in case when fields differ it is likely > - that lengths differ too and checking fields is more expensive > - in general case. > + if the user key part length is different. > */ > - if (key_part->length != new_part->length) > + if (key_part->length != new_part->length && > + (ha_alter_info->alter_info->flags & Alter_info::ALTER_CHANGE_COLUMN) && why is that? Can it happen that ALTER_CHANGE_COLUMN flag is not set? > + (key_part->field->is_equal((Create_field*) new_field) > + == IS_EQUAL_PACK_LENGTH)) > + { > + ha_alter_info->handler_flags |= > + Alter_inplace_info::ALTER_COLUMN_INDEX_LENGTH; > + } > + else if (key_part->length != new_part->length) > goto index_changed; > > - new_field= get_field_by_index(alter_info, new_part->fieldnr); > - > /* > For prefix keys KEY_PART_INFO::field points to cloned Field > object with adjusted length. So below we have to check field Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] b0d21b7: MDEV-14567 Include full name of object in message about incorrect value for column.
by Sergei Golubchik 05 Nov '18

05 Nov '18

Hi, Alexey! On Nov 04, Alexey Botchkov wrote: > revision-id: b0d21b7832cea92522d0f8d280ceb8b13b335cbf (mariadb-10.2.18-56-gb0d21b7) > parent(s): 1c6b982e02eeaa75bb6c2f2a3c2b64491dd6d3c8 > committer: Alexey Botchkov > timestamp: 2018-11-04 09:14:40 +0400 > message: > > MDEV-14567 Include full name of object in message about incorrect value for column. Wrong MDEV number again. It should be MDEV-14576 > > Put the full field name in the ER_TRUNCATED_WRONG_VALUE_FOR_FIELD > error message. > > +static char *long_field_name(char *buf, size_t buf_len, > + const TABLE_SHARE *s, const char *field_name) > +{ > + bool is_temp= !s|| > + (tmp_file_prefix_length < s->table_name.length && > + memcmp(s->table_name.str, > + tmp_file_prefix, tmp_file_prefix_length) == 0); > + > + if (is_temp) > + strxnmov(buf, buf_len, "{temporary}.", field_name, NullS); > + else > + strxnmov(buf, buf_len, > + s->db.str, ".", s->table_name.str, ".", field_name, NullS); > + > + return buf; > +} > + > + > int Field_geom::store(const char *from, uint length, CHARSET_INFO *cs) > { > if (!length) > @@ -8620,10 +8638,11 @@ int Field_geom::store(const char *from, uint length, CHARSET_INFO *cs) > geom_type != Field::GEOM_GEOMETRYCOLLECTION && > (uint32) geom_type != wkb_type) > { > + char buf[193]; > my_error(ER_TRUNCATED_WRONG_VALUE_FOR_FIELD, MYF(0), > Geometry::ci_collection[geom_type]->m_name.str, > Geometry::ci_collection[wkb_type]->m_name.str, > - field_name, > + long_field_name(buf, sizeof(buf), table->s, field_name), > (ulong) table->in_use->get_stmt_da()-> > current_row_for_warning()); > goto err_exit; Better change the error message to be Incorrect decimal value: '%s' for column %`s.%`s.%`s at row %d and use like my_error(ER_TRUNCATED_WRONG_VALUE_FOR_FIELD, MYF(0), Geometry::ci_collection[geom_type]->m_name.str, Geometry::ci_collection[wkb_type]->m_name.str, - field_name, + table->s->db.str, table->s->table_name.str, field_name, (ulong) table->in_use->get_stmt_da()-> current_row_for_warning()); What would that do for temporary tables? Anyway, the correct quoting is still `db`.`table`.`column`, not 'db.table.column'. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MDEV-15740 (InnoDB lost Durability due to incorrect fix of MDEV-11937)
by Marko Mäkelä 02 Nov '18

02 Nov '18

Hi Kristian, Could you please take a look at this InnoDB regression in MariaDB 10.2 and later: https://jira.mariadb.org/browse/MDEV-15740 Because of this bug, we can no longer write tests that would ensure that certain changes are present in the redo log, before killing and restarting the server. This already hurt me a bit when testing MDEV-15562 (instant DROP COLUMN) in 10.4. I had to add extra sleeps to test cases in order to actually test redo log roll-forward followed by rollback. -- Marko Mäkelä, Lead Developer InnoDB MariaDB Corporation

2 3

Re: [Maria-developers] [Commits] 737de39: Issue #885: Can't locate lib/mtr_process.pl in @INC on Ubuntu 18.04.1
by Kristian Nielsen 02 Nov '18

02 Nov '18

Hi Sergey, psergey(a)askmonty.org (Sergei Petrunia) writes: > committer: Sergei Petrunia > branch nick: mysql-5.6-rocksdb-spetrunia > Issue #885: Can't locate lib/mtr_process.pl in @INC on Ubuntu 18.04.1 > > Add "." to @INC array like upstream does. Just want to make sure you are aware of this: https://github.com/MariaDB/server/commit/d185f1d68bb1f37bea10d8ac6188e5a04f… I see the branch nick is mysql-5.6-<something>, so maybe this is like this for legacy reasons, which is fine. But this is basically the wrong fix. Clearly sometimes in ancient history, someone did not understand Perl `require` semantics, and ended up with a horrible mess. For example, if someone ever finds they need `require mtr_misc.pl` in a third file, they will find it will not work. Anyway, just a pointer in case you were not aware of a small land-mine hidden under your feet ;-) - Kristian.

2 1

Re: [Maria-developers] f95616dc477: MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF error and corrupt index
by Sergei Golubchik 31 Oct '18

31 Oct '18

Hi, Oleksandr! ok to push! On Oct 30, Oleksandr Byelkin wrote: > revision-id: f95616dc4774328381044b53263d6a23ae19bfb4 (mariadb-5.5.61-39-gf95616dc477) > parent(s): 893ebb739e24637985892da1555f2e6f1a8ac5b6 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-10-30 19:36:17 +0100 > message: > > MDEV-17401: LOAD DATA from very big file into MyISAM table results in EOF error and corrupt index > > my_read fixed as in higher versions. > my_pread made as my_read aware of partial read of huge chunks of files > MY_FULL_IO enabled for file operations > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] c29706f: MDEV-17286 Decimal field multiplication bug.
by Sergei Golubchik 30 Oct '18

30 Oct '18

Hi, Alexey! On Oct 30, Alexey Botchkov wrote: > > What if both arguments will be zeros, but have intg=DIG_PER_DEC1-1. > > Won't the result have more that DIG_PER_DEC1 zeros? > > Leading zero 'digits' are truncated, so we never get more than DIG_PER_DEC > there. Actually we don't need to do that check at all (intg <= > DIG_PER_DEC1), > i removed it already. Put it in an assert please. I find asserts quite useful as a documentation tool :) Then ok to push! Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] c29706f: MDEV-17286 Decimal field multiplication bug.
by Sergei Golubchik 30 Oct '18

30 Oct '18

Hi, Alexey! On Oct 24, Alexey Botchkov wrote: > revision-id: c29706f7560148488791acca3c92dde1b188334e (mariadb-5.5.61-32-gc29706f) > parent(s): e31e697f17f79ffa6913499e7e2d29866f24b475 > committer: Alexey Botchkov > timestamp: 2018-10-24 01:26:49 +0400 > message: > > MDEV-17286 Decimal field multiplication bug. > > We should clear trailing zeroes in frac part. Otherwise > that tail is growing quickly and forces unnecessary truncating of > arguments. This looks good, thanks. Please add a test for create select, as discussed. And fix the bug number in the commit comment. See one question below. > @@ -2109,6 +2104,14 @@ int decimal_mul(const decimal_t *from1, const decimal_t *from2, decimal_t *to) > for (; d_to_move--; cur_d++, buf1++) > *cur_d= *buf1; > } > + > + /* Now we have to check for -0.000 case */ > + if (to->sign && to->intg <= DIG_PER_DEC1 && to->frac == 0 && > + to->buf[0] == 0) What if both arguments will be zeros, but have intg=DIG_PER_DEC1-1. Won't the result have more that DIG_PER_DEC1 zeros? > + { > + /* We got decimal zero */ > + decimal_make_zero(to); > + } > return error; > } > Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0