List:Internals« Previous MessageNext Message »
From:Timothy P Clark Date:December 2 2009 7:40pm
Subject:Re: Bad example in example storage engine
View as plain text  
Thanks, Sergei.

Unfortunately, the ha_data solution has its own problems with partitioned 
tables--for our storage engine at least. Because there is only one 
TABLE_SHARE for all partitions, any information that needs to be shared 
among all handlers attached to a particular partition (but segregated from 
handlers of other partitions) still has to use the mangled partition file 
name ("blah#P#p1") to differentiate. I suppose we could build an array of 
STORAGE_ENGINE_SHAREs into ha_data on the basis of the partition 
information known to the storage engine. However, we would like our engine 
to be as ignorant of the partitioning scheme as possible (and comments in 
table.h lead me to believe this is also the intended direction for the 
storage engine architecture.) Is there some better way to handle the 
partitioning case?

Tim Clark

Sergei Golubchik <serg@stripped> wrote on 12/02/2009 03:31:23 AM:

> Re: Bad example in example storage engine
> Sergei Golubchik 
> to:
> Timothy P Clark
> 12/02/2009 03:34 AM
> Cc:
> internals
> 
> Hi, Timothy!
> 
> Thanks.
> I've submitted it as http://bugs.mysql.com/49329
> 
> Note that
> 
> 1. there is a user visible incorrect behavior, so it's clearly a bug.
> 
> 2. my_charset_bin is probably also incorrect, it'll result in a wrong
>    behavior when lower_case_table_names is enabled, table_alias_charset
>    is the one to use.
> 
> 3. the recommended solution is to remove the hash completely and use
>    TABLE_SHARE::ha_data - it was added in 5.1 precisely for this
>    purpose, so that engines wouldn't need to maintain the mapping from
>    table names to shares, MySQL already does it anyway, the engine can
>    simply use it - remove the hash, the mutex to guard it, and simply
>    store the pointer in the TABLE_SHARE::ha_data, if possible.
> 
> On Dec 01, Timothy P Clark wrote:
> > I've found what I believe to be a problem with the example storage 
engine. 
> > The problem also exists in the InnoDB and CSV storage engines. 
Strictly 
> > speaking, I can't call it a bug, since I don't think that any adverse 
> > behavior is generated for these cases. However, it does adversely 
affect 
> > our storage engine, which long ago used the example storage engine as 
its 
> > inspiration. Consequently, I would suggest that the example storage 
engine 
> > be fixed to prevent future storage engines from making a similar 
mistake.
> > 
> > The problem is this: in the storage engine initialization function 
> > (example_init_func), the example_open_tables hash table is initialized 
to 
> > use the system_charset_info character set. This hash table is used to 
> > track information on a table-wide basis that is shared among handlers 
> > belonging to that table. However, because system_charset_info uses the 

> > utf8_general_ci collation, table names that differ only in letter case 

> > (e.g. ABC and abc) will hash to the same share. When our storage 
engine 
> > has two such tables open at the same time, odd behavior occurs because 
of 
> > this collision. I suspect that the appropriate solution is to use 
> > my_charset_bin instead of system_charset_info, as the federated engine 

> > does.
> > 
> > Thank you,
> > Tim Clark
> > 
> > 
> > -- 
> > MySQL Internals Mailing List
> > For list archives: http://lists.mysql.com/internals
> > To unsubscribe:    
http://lists.mysql.com/internals?unsub=1
> > 
> Regards / Mit vielen Grüßen,
> Sergei
> 
> -- 
>    __  ___     ___ ____  __
>   /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
>  / /|_/ / // /\ \/ /_/ / /__  Principal Software Engineer/Server 
Architect
> /_/  /_/\_, /___/\___\_\___/  Sun Microsystems GmbH, HRB München 161028
>        <___/                  Sonnenallee 1, 85551 Kirchheim-Heimstetten
> Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
> Vorsitzender des Aufsichtsrates: Martin Häring

Thread
Bad example in example storage engineTimothy P Clark1 Dec
  • Re: Bad example in example storage engineSergei Golubchik2 Dec
    • Re: Bad example in example storage engineTimothy P Clark2 Dec
      • Re: Bad example in example storage engineSergei Golubchik17 Jan