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
