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>
> >
> >
> >
> >
>
