From: Date: April 18 2006 9:30am
Subject: Re: getting table meta data (primary key, in this case)
List-Archive: http://lists.mysql.com/internals/33520
Message-Id: <20060418073032.GA79637@serg.mylan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Hi!

On Apr 15, Eric Prud'hommeaux wrote:
> On Mon, Apr 10, 2006 at 12:17:54PM +0200, Sergei Golubchik wrote:

> > and only after all tables are opened, MySQL calls
> > Item_field::fix_fields() for all Item_field's, and it's the method where
> > "binding" happens - a field finds what table and database it belongs to,
> > finds all metadata about itself, data type, constrains, indexes, and so
> > on.
> 
> worky (and quite easily)!!! Thank you SO much for the pointer!

Glad to hear that!
 
> [[
> bool Item_variable::fix_fields(THD *thd, Item **reference) {
>   if (primary_key)
>     field_name = get_primary_key();
>   return Item_field::fix_fields(thd, reference);
> }
> 
> const char* sparqlFrob::get_primary_key(const char *table_name) {
>   TABLE_LIST *entry = thd->main_lex.select_lex.context.table_list;
>   while (entry) {
>     if (!strcmp(table_name, entry->table_name)) {
>       KEY *key = entry->table->key_info;
>       for (unsigned i = 0; i < entry->table->s->keys; i++) { // from sql_show.cc::2905 get_schema_stat_record
> 	if (!strcmp(key[i].name, "PRIMARY")) {
> 	  assert(key[i].key_parts == 1);
> 	  return key[i].key_part->field->field_name;
> 	}

Strictly speaking, primary key is _always_ the first one, so it's enough
to check entry->table->key_info[0].

>       }
>       assert(0); // couldn't find PRIMARY KEY
>     }
>     entry = entry->next_global;
>   }
>   assert(0); // couldn't find table
> }
> ]]
> It brings up 2 questions:
> 
>   Is there a way to kill a thread ('cause something went horribly
>   wrong), without killing the whole server? What's the polite way to
>   assert(0)?

Usually you just throw an error (my_error(...)), and return an failure,
which is usually non-zero in MySQL source (with zero meaning success).
It assumes, of course, that the caller checks return values.

Kill a thread - technically you can do that, set THD::killed
(grep to see how it's used). But

 - it was designed for asynchronous use - when a thread is killed by some
   other thread
 - it's "advisory" killing - a thread checks THD::killed in certain
   places and returns an error if it's set. It may not die immediately.
 - I would not recommend doing it anyway - users do not expect a
   connection being killed on an error, they want an error message.
   And if you kill the connection - be ready for bugreports "MySQL
   server crashed", because not everybody will try to understand what is
   the reason for the error message "Lost connection to MySQL server
   during query". I saw many bugreports about "crashes" which in fact
   the problem was a disconnect.

>   Is there a better way to find the table_list for a thread? I feel
>   like thd->main_lex.select_lex.context.table_list should really
>   include some inode numbers, the process id and maybe some astrology.

Eh, this part of code has changed quite a lot recently, I'm not up to
date :(

I'll ask another developer to reply.

Regards,
Sergei

-- 
   __  ___     ___ ____  __
  /  |/  /_ __/ __/ __ \/ /   Sergei Golubchik <serg@stripped>
 / /|_/ / // /\ \/ /_/ / /__  MySQL AB, Senior Software Developer
/_/  /_/\_, /___/\___\_\___/  Kerpen, Germany
       <___/  www.mysql.com