[MDEV-13920] optimize table not erroring correctly Created: 2017-09-27  Updated: 2017-11-05  Resolved: 2017-11-05

Status: Closed
Project: MariaDB Server
Component/s: Admin statements
Affects Version/s: 5.5.50
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Lori Patrick Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: need_feedback
Environment:

we are running MariaDB 5.5.50 on CentOS 7.2


 Description   

If you run optimize table on a table that does not exist you get the following message:

optimize table traders_test;

Table Op Msg_type Msg_text
tradegraph_db.traders_test optimize Error Table 'tradegraph_db.traders_test' doesn't exist
tradegraph_db.traders_test optimize status Operation failed

If you are running the sql_error_log plugin, you can see an error is generated:
ERROR 1146: Table 'tradegraph_db.traders_test' doesn't exist : optimize table traders_test

However, the optimize table command is written to the binary log which is counter intuitive. In the case of a replication slave, if the object doesn't exist on the slave, it does not pass the error back to the replication thread. So the replication thread thinks it was fine, when in fact the object did not exist. My assumption would be the thread should crash like other sql error would break replication no ignore the error and continue.



 Comments   
Comment by Elena Stepanova [ 2017-09-30 ]

Sorry, I didn't understand the replication issue you are trying to describe, could you please rephrase it, or better still, provide an example where the existing behavior causes actual harm?
OPTIMIZE TABLE is written to binary log by default, yes. It's read and executed by the slave, yes. Why is it a problem?

For the "counter-intuitiveness" of it, it's arguable (as it always is when it comes to intuition). OPTIMIZE itself does not actually fail, it catches all errors it encounters and presents them to the user, but the command as such succeeds. If you think of it from this perspective, it's only natural that it's written to the binlog anyway.

If you don't want OPTIMIZE in the binary log, you can always use NO_WRITE_TO_BINLOG keyword.

Finally, for sql_error_log plugin, yes, this behavior might be questionable, but then again – it's defined as "plugin which collects errors sent to clients in a log file". The error was indeed sent to a client, even though it wasn't an exit status of OPTIMIZE command, so why not to log it?

Generated at Thu Feb 08 08:09:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.