List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:April 2 2001 10:01am
Subject:Re: Hacking triggers into 2.23.34a?
View as plain text  
Hi!

>>>>> "barries" == barries  <barries@stripped> writes:

barries> On Mon, Apr 02, 2001 at 12:54:23AM +0300, Michael Widenius wrote:
>> 
>> For a test of where they change try to do two updates with a FLUSH
>> TABLES in between...

barries> The triggers are deleted in free_cache_entry() and reinstantiated in
barries> open_table(), do doing a flush tables deletes and recreates the tables
barries> (see my post from friday afternoon for a transcript).

The nice thing with having all field references indirect is that you
would only need one global instance of the triggers.
On the other hand, the above scenario should work.

barries> My problem, so far anyway, is keeping the nodes in a List<Field> around
barries> just in the interval between an open_table() and when the query actually
barries> executes, when the tables are being opened for the first time for this
barries> query.

barries> Normally, I'm restarting mysqld between queries while testing.  I
barries> restart the server and issue the query 

barries> update foo set a=not a;

barries> in the client, which cause the client to reestablish the connection,
barries> open foo, and run the query.  Sometime between the open_table() and the
barries> guts of the query where the trigger fires, the List<Field> I've used to
barries> cache a pointer to the TABLE's fields has some of it's nodes corrupted.

What is it that gets corrupted?  The TABLE field or the list?
Note that if you create the trigger fields OUTSIDE of openfrm, the
fields will be automaticly freed when the query ends.

This is the purpose of sql_memdup in the following function:

  inline Field *new_field(struct st_table *new_table)
    {
      Field *tmp= (Field*) sql_memdup((char*) this,size_of());
      if (tmp)
      {
        tmp->table=new_table;
        tmp->key_start=tmp->part_of_key=tmp->part_of_sortkey=0;
        tmp->unireg_check=Field::NONE;
        tmp->flags&= (NOT_NULL_FLAG | BLOB_FLAG | UNSIGNED_FLAG | ZEROFILL_FLAG
| BINARY_FLAG | ENUM_FLAG | SET_FLAG);
        tmp->reset_fields();
      }
      return tmp;
    }


openfrm() does the following to avoid its memory to be automaticly
freed:


  init_sql_alloc(&outparam->mem_root,1024,0);
  MEM_ROOT *old_root=my_pthread_getspecific_ptr(MEM_ROOT*,THR_MALLOC);
  my_pthread_setspecific_ptr(THR_MALLOC,&outparam->mem_root);

....

  my_pthread_setspecific_ptr(THR_MALLOC,old_root);

barries> Are List<>'s list_node instances, which are derived from class
barries> Sql_alloc, likely to evaporate when a thread does some sort of cleanup?

Yes, if you are not protecting these with your own MEM_ROOT *object;
If you have your own mem_root object, you can free everything by
just doing:

free_root( &mem_root, MYF(0));

The code is in mysys/my_alloc.c

Regards,
Monty
Thread
Hacking triggers into 2.23.34a?barries29 Mar
  • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?barries29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
    • Re: Hacking triggers into 2.23.34a?Jeremy D . Zawodny29 Mar
      • Re: Hacking triggers into 2.23.34a?elble29 Mar
        • Re: Hacking triggers into 2.23.34a?barries29 Mar
          • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
          • Re: Hacking triggers into 2.23.34a?barries30 Mar
            • Re: Hacking triggers into 2.23.34a?Michael Widenius31 Mar
        • Re: Hacking triggers into 2.23.34a?Sasha Pachev30 Mar
  • Re: Hacking triggers into 2.23.34a?Antony T Curtis30 Mar
  • Hacking triggers into 2.23.34a?Michael Widenius31 Mar
    • Re: Hacking triggers into 2.23.34a?barries31 Mar
      • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
        • Re: Hacking triggers into 2.23.34a?barries1 Apr
          • Re: Hacking triggers into 2.23.34a?barries1 Apr
            • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
              • Re: Hacking triggers into 2.23.34a?barries2 Apr
                • Re: Hacking triggers into 2.23.34a?Michael Widenius2 Apr
          • Re: Hacking triggers into 2.23.34a?Michael Widenius1 Apr
  • SQL92?Antony T Curtis2 Apr