Hi,
After taking a look at reload_acl_and_cache, it seems the flag REFRESH_TABLE
is usefull only if REFRESH_QUERY_CACHE or REFRESH_READ_LOCK is set :
if (options & (REFRESH_TABLES | REFRESH_QUERY_CACHE))
{
query_cache.flush(); // RESET QUERY CACHE
}
#endif /*HAVE_QUERY_CACHE*/
if (options & (REFRESH_TABLES | REFRESH_READ_LOCK))
{
if ((options & REFRESH_READ_LOCK) && thd)
{
if (lock_global_read_lock(thd))
return 1;
}
result=close_cached_tables(thd,(options & REFRESH_FAST) ? 0 : 1, tables);
}
However flags passed at reload_acl_and_cache during a SIGHUP are :
REFRESH_LOG | REFRESH_TABLES | REFRESH_FAST |
REFRESH_STATUS | REFRESH_GRANT | REFRESH_THREADS |
REFRESH_HOSTS
So no REFRESH_READ_LOCK nor REFRESH_QUERY_CACHE here. Moreover REFRESH_FAST
is only used in reload_acl_and_cache if REFRESH_READ_LOCK is set.
It why I'm wondering if REFRESH_READ_LOCK is not missing in mysqld.cc during
the call to reload_acl_and_cache (
I've changed REFRESH_HOSTS to REFRESH_HOSTS | REFRESH_READ_LOCK, and will
see if the waiting for table problem still occurs), since
close_cached_tables seems to flush also delayed tables.
Regards,
Jocelyn
----- Original Message -----
From: "Jocelyn Fournier" <joc@stripped>
To: <monty@stripped>
Cc: <internals@stripped>; <sroussey@stripped>
Sent: Wednesday, October 02, 2002 2:27 AM
Subject: Re: Problem with insert delayed thread. More clues...
> Hi,
>
> I'm now sure the problem happens when mysql enter in the SIGHUP case, so
the
> problem in somewhere in signal_hand in mysqld.cc. However
mysql_print_status
> is not the problem (same problem after removing mysql_print_status).
> However I don't know if the problem is in reload_acl_and_cache or before.
>
> (How does this code work ? :
>
> /*
> signal to start_signal_handler that we are ready
> This works by waiting for start_signal_handler to free mutex,
> after which we signal it that we are ready.
> At this pointer there is no other threads running, so there
> should not be any other pthread_cond_signal() calls.
> */
> (void) pthread_mutex_lock(&LOCK_thread_count);
> (void) pthread_mutex_unlock(&LOCK_thread_count);
> (void) pthread_cond_broadcast(&COND_thread_count);
> )
>
> Thanks and regards,
> Jocelyn
>
>
> ----- Original Message -----
> From: "Jocelyn Fournier" <joc@stripped>
> To: <monty@stripped>
> Cc: <internals@stripped>; <sroussey@stripped>
> Sent: Tuesday, October 01, 2002 10:20 PM
> Subject: Re: Problem with insert delayed thread. More clues...
>
>
> > Hi Monty,
> >
> > After taking a look at my .err file, it seems mysql_print_status is
called
> > before a waiting_for_table problem.
> > This function seems to be called when a sighup occurs according to this
> code
> > in mysqld.cc :
> >
> > case SIGHUP:
> > reload_acl_and_cache((THD*) 0,
> > (REFRESH_LOG | REFRESH_TABLES | REFRESH_FAST
|
> > REFRESH_STATUS | REFRESH_GRANT |
> REFRESH_THREADS
> > |
> > REFRESH_HOSTS),
> > (TABLE_LIST*) 0); // Flush logs
> > mysql_print_status((THD*) 0); // Send debug some info
> > break;
> >
> > It also makes sense since this part of the code calls REFRESH_STATUS,
> which
> > was entailing the thread_delayed_insert reset problem I already noticed
> and
> > which is now fixed.
> > Moreover SIGHUP appears more often under high load than under normal
> > condition.
> >
> > Is this possible mysql_print_status somehow lock a delayed thread but
> didn't
> > release the lock ?
> > Here is an exemple of what is written in the err file :
> >
> > Status information:
> >
> > Current dir: /home/mysql/
> > Current locks:
> > lock: 4b31a314:
> >
> > lock: 4b713824:
> >
> > lock: 88a5c64:
> >
> > lock: 869fa54:
> >
> > lock: 83d3d74:
> >
> > lock: 8bd9b0c:
> >
> > lock: 8bd8224:
> >
> > lock: 8bd66cc:
> >
> > lock: 8bd10bc:
> >
> > lock: 8bcf584:
> >
> > lock: 8a874bc:
> >
> > lock: 83d4eec:
> >
> > lock: 892c63c:
> >
> > lock: 86c6a84:
> >
> > lock: 89f311c:
> >
> > lock: 89f19cc:
> >
> > lock: 86ad94c:
> >
> > lock: 8ba747c:
> >
> > lock: 873a73c:
> >
> > lock: 86eb33c:
> >
> > lock: 8976394:
> >
> > lock: 86d42dc:
> >
> > lock: 877e36c:
> >
> > lock: 8858a6c:
> >
> > lock: 8a92d8c:
> >
> > lock: 8991f0c:
> >
> > lock: 5c575cac:
> >
> > lock: 5bc0123c:
> >
> > lock: 5c56fad4:
> >
> > lock: 5c3e20fc:
> >
> > lock: 5c3eda5c:
> >
> > lock: 89c33ac:
> >
> > lock: 89bade4:
> >
> > lock: 899abec:
> >
> > lock: 89b5fcc:
> >
> > lock: 89ac75c:
> >
> > lock: 88e0c94:
> >
> > lock: 5c2584ac:
> >
> > lock: 89ac0dc:
> >
> > lock: 888bf14:
> >
> > lock: 8934264:
> >
> > lock: 4b00536c:
> >
> > lock: 5bc2f39c:
> >
> > lock: 5bc48164:
> >
> > lock: 5bc41d2c:
> >
> > lock: 4b01ec5c:
> >
> > lock: 885c504:
> >
> > lock: 885aa84:
> >
> > lock: 8896474:
> >
> > lock: 8878194:
> >
> > lock: 8873e74:
> >
> > lock: 87b055c:
> >
> > lock: 5bc24254:
> >
> > lock: 87e90cc:
> >
> > lock: 5be16044:
> >
> > lock: 87a6c44:
> >
> > key_cache status:
> > blocks used: 103673
> > not flushed: 0
> > w_requests: 0
> > writes: 0
> > r_requests: 3
> > reads: 3
> >
> > handler status:
> > read_key: 1
> > read_next: 0
> > read_rnd 0
> > read_first: 2
> > write: 0
> > delete 0
> > update: 0
> >
> > Table status:
> > Opened tables: 3
> > Open tables: 41
> > Open files: 81
> > Open streams: 0
> >
> > Alarm status:
> > Active alarms: 1
> > Max used alarms: 94
> > Next alarm time: 11
> >
> > Anyway I will try to modify the code to
> >
> > #ifndef DBUG_OFF
> >
> > mysql_print_status((THD*) 0); // Send debug some info
> >
> > #endif
> >
> > to see if the insert_delayed waiting_for_table problem still occurs for
> me.
> >
> >
> > Regards,
> > Jocelyn
> >
> >
> > ----- Original Message -----
> > From: "Michael Widenius" <monty@stripped>
> > To: "Jocelyn Fournier" <joc@stripped>
> > Cc: <internals@stripped>
> > Sent: Friday, September 27, 2002 10:49 AM
> > Subject: Problem with insert delayed thread. Perhaps a linuxthread
problem
> ?
> >
> >
> > >
> > > Hi!
> > >
> > > >>>>> "Jocelyn" == Jocelyn Fournier
> <joc@stripped> writes:
> > >
> > > Jocelyn> Hi,
> > > Jocelyn> I want to sum up here the problems I encounter with insert
> > delayed thread.
> > > >> From time to time (quite rare, but I reproduced the problem on
> several
> > > Jocelyn> servers), the insert delayed thread seems to "lock" the
table.
> > (all process
> > > Jocelyn> are in "waiting for the table" state)
> > >
> > > <cut>
> > >
> > > >> DESTRUCTOR CALLED ; delayed_insert_threads : 42
> > > >> dest Mutex addr : 141851908
> > > >> pthread_handler_decl (end:), destructor called mutex addr
147339436;
> > > >> delayed_insert_threads : 0
> > > >> DESTRUCTOR CALLED ; delayed_insert_threads : 0
> > >
> > > <cut>
> > >
> > > Jocelyn> It seems something reinitialize delayed_insert_threads
between
> > the 141851908
> > > Jocelyn> mutex and the 147339436.
> > >
> > > This is very strange; As you said it's only in the
> > > constructor/destructor delayed_insert_threads are changed.
> > >
> > > checking....
> > >
> > > ok, finally found and tracked down this long time bug...
> > > It was wrongly reset on 'FLUSH STATUS'
> > >
> > > Will push the fix into 3.23 and 4.0 today.
> > > (This will not fix the waiting for tables problems, for this we need
> > > another test case)
> > >
> > > Regards,
> > > Monty
> > >
> > > --
> > > For technical support contracts, goto https://order.mysql.com/
> > > __ ___ ___ ____ __
> > > / |/ /_ __/ __/ __ \/ / Mr. Michael Widenius
> <monty@stripped>
> > > / /|_/ / // /\ \/ /_/ / /__ MySQL AB, CTO
> > > /_/ /_/\_, /___/\___\_\___/ Helsinki, Finland
> > > <___/ www.mysql.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > Before posting, please check:
> > > http://www.mysql.com/manual.php (the manual)
> > > http://lists.mysql.com/ (the list archive)
> > >
> > > To request this thread, e-mail internals-thread4828@stripped
> > > To unsubscribe, e-mail <internals-unsubscribe@stripped>
> > >
> > >
> > >
> > >
> >
>
