When using --log --log-output=table, we increment Table_locks_immediate
with every query. The wait_condition.inc runs a query a variable number
of times, depending on server load, etc. This is a problem, when the
test is checking the Table_locks_immediate value.
Fix is to adjust the Table_locks_immediate value based on how many times
the wait_condition query was executed.
BUG#26429: SHOW CREATE EVENT is incorrect for an event that
STARTS NOW()
BUG#26431: Impossible to re-create an event from backup if its
STARTS clause is in the past
WL#3698: Events: execution in local time zone
The problem was that local times specified by the user in AT, STARTS
and ENDS of CREATE EVENT/ALTER EVENT statement were converted to UTC,
and the original time zone was forgotten. This way, event scheduler
couldn't honor Daylight Saving Time shifts, and times shown to the
user were also in UTC. Additionally, CREATE EVENT didn't allow times
in the past, thus preventing straightforward event restoration from
old backups.
This patch reworks event scheduler time computations, performing them
in the time zone associated with the event. Also it allows times to
be in the past.
The patch adds time_zone column to mysql.event table.
NOTE: The patch is almost final, but the bug#9953 should be pushed
first.
The problem was that the events_bugs test could randomly fail due to
races in the test case.
The solution is to replace fixed sleeps with reliable polling of a
certain state to settle. For that, a new auxiliary script
include/wait_condition.inc is used, that allows waiting for a given
query to return true.
