Bug#54783: optimize table crashes with invalid timestamp default
value and NO_ZERO_DATE The problem was that a older version of the error path for a failed admin statement relied upon a few error conditions being met in order to access a table handler, the first one being that the table object pointer was not NULL. Probably due to chance, in all cases a table object was closed but the reference wasn't reset, the other conditions didn't evaluate to true. With the addition of a new check on the error path, the handler started being dereferenced whenever it was not reset to NULL, causing problems for code paths which closed the table but didn't reset the reference. The solution is to reset the reference whenever a admin statement fails and the tables are closed.
Showing
Please register or sign in to comment