-
Marc Alff authored
Before this fix, when a - wait - stage - statement - transaction (in 5.7) was still executing, respective tables - performance_schema.events_waits_current - performance_schema.events_stages_current - performance_schema.events_statements_current - performance_schema.events_transactions_current (in 5.7) would display the event with - TIMER_START populated - TIMER_END as NULL - TIMER_WAIT as NULL This makes it difficult to find for how long an event not yet completed has been running. With this fix, - TIMER_START is populated (unchanged) - TIMER_END is populated with the current timer value (NOW) - TIMER_WAIT is populated with the time elapsed so far (TIMER_END - TIMER_START) Monitoring applications can simply query WHERE (END_EVENT_ID IS NULL) and (TIMER_WAIT > X) to find out events that are: - not yet completed (no END_EVENT_ID) - taking longer than X picoseconds already.
Marc Alff authoredBefore this fix, when a - wait - stage - statement - transaction (in 5.7) was still executing, respective tables - performance_schema.events_waits_current - performance_schema.events_stages_current - performance_schema.events_statements_current - performance_schema.events_transactions_current (in 5.7) would display the event with - TIMER_START populated - TIMER_END as NULL - TIMER_WAIT as NULL This makes it difficult to find for how long an event not yet completed has been running. With this fix, - TIMER_START is populated (unchanged) - TIMER_END is populated with the current timer value (NOW) - TIMER_WAIT is populated with the time elapsed so far (TIMER_END - TIMER_START) Monitoring applications can simply query WHERE (END_EVENT_ID IS NULL) and (TIMER_WAIT > X) to find out events that are: - not yet completed (no END_EVENT_ID) - taking longer than X picoseconds already.
Loading