Hello,
Alexey Botchkov a écrit, Le 23.06.2009 17:13:
> > Do you know what revision introduced this change?
> > If we knew, we could maybe check for other places which need an update.
>
> That was introduced by this fix:
> http://lists.mysql.com/commits/61988
Thanks for the link!
> > which probably has the same bug (I grepped for "str[0]" in sql/). Could
> > you please create a test query for this place (hopefully triggering the
> > assertion), and fix this place?
>
> Right, this line also should be fixed, but i wasn't able to make these
> working and Timour told that he didn't mean these lines will ever be
> executed, so dunno.
I found a way to reproduce the assert in
Field_iterator_table_ref::get_db_name(). This assertion was amended by
Timour to eliminate an assertion failure in BUG#17523 according to
"bzr gannotate".
The testcase of that bug was
select * from information_schema.statistics join information_schema.columns
using(table_name,column_name) where table_name='user';
However, when I run this query on the current mysql-azalea, the
assertion does not fire, because
table_ref->db and table_ref->table->s->db.str are both
"information_schema" so !strcmp returns true.
But by changing the query to use capital letters:
select * from INFORMation_schema.statistics join
INFormation_schema.columns using(table_name,column_name) where
table_name='user';
then table_ref->db is "INFORMation_schema", table_ref->table->s->db.str
is "information_schema", so !strcmp is false, and we go into the second
branch of the assertion, where table_ref->table->s->db.str[0] == 0 is false.
> So i submitted the new patch with that line fixed in the same way.
Thanks, I will recap by replying to that new patch.
> Regards
> HF
>
>
> Guilhem Bichot wrote:
>> Hello Holyfoot,
>>
>> Alexey Botchkov a écrit, Le 21.05.2009 14:21:
>>> #At file:///home/hf/work/mysql_common/43834/ based on
>>> revid:alexey.kopytov@stripped
>>>
>>> 3311 Alexey Botchkov 2009-05-21
>>> Bug#43834 Assertion in Natural_join_column::db_name() on
>>> an I_S query
>>> starting with the 6.0 we have 'information_schema' as the db
>>> name for
>>> the information schema tables.
>>
>> Do you know what revision introduced this change?
>> If we knew, we could maybe check for other places which need an update.
>>
>>> So that we need to use is_schema() test
>>> to check.
>>> per-file comments:
>>> mysql-test/t/information_schema.test
>>> Bug#43834 Assertion in Natural_join_column::db_name() on
>>> an I_S query
>>> test case added. Test result should be modified later when
>>> this test
>>> is enabled.
>>
>> Ok, as long as the added test portion does not crash anymore :)
>>
>>> === modified file 'sql/table.cc'
>>> --- a/sql/table.cc 2009-05-07 20:48:24 +0000
>>> +++ b/sql/table.cc 2009-05-21 12:17:56 +0000
>>> @@ -4035,7 +4035,7 @@ const char *Natural_join_column::db_name
>>> DBUG_ASSERT(!strcmp(table_ref->db,
>>> table_ref->table->s->db.str) ||
>>> (table_ref->schema_table &&
>>> - table_ref->table->s->db.str[0] == 0));
>>> + is_schema_db(table_ref->table->s->db.str)));
>>> return table_ref->db;
>>> }
>>
>> There is also, in table.cc:
>>
>> const char *Field_iterator_table_ref::get_db_name()
>> {
>> if (table_ref->view)
>> return table_ref->view_db.str;
>> else if (table_ref->is_natural_join)
>> return natural_join_it.column_ref()->db_name();
>>
>> /*
>> Test that TABLE_LIST::db is the same as TABLE_SHARE::db to
>> ensure consistency. An exception are I_S schema tables, which
>> are inconsistent in this respect.
>> */
>> DBUG_ASSERT(!strcmp(table_ref->db, table_ref->table->s->db.str) ||
>> (table_ref->schema_table &&
>> table_ref->table->s->db.str[0] == 0));
>>
>> return table_ref->db;
>> }
>>
>> which probably has the same bug (I grepped for "str[0]" in sql/).
>> Could you please create a test query for this place (hopefully
>> triggering the assertion), and fix this place?
>>
>> Thanks!
>>
--
Mr. Guilhem Bichot <guilhem@stripped>
Sun Microsystems / MySQL, Lead Software Engineer
Bordeaux, France
www.sun.com / www.mysql.com
