MySQL Bugs: #22077: DROP TEMPORARY TABLE fails with wrong error if read

Bug #22077	DROP TEMPORARY TABLE fails with wrong error if read_only is set
Submitted:	7 Sep 2006 13:00	Modified:	21 Dec 2006 21:19
Reporter:	Domas Mituzas
Status:	Closed
Category:	Server: General	Severity:	S3 (Non-critical)
Version:	5.0, 5.1	OS:	Linux (Linux, any)
Assigned to:	Alexey Kopytov	Target Version:
Tags:	temporary read_only

Description:
If table does not exist, and read_only is set, server complains about --read-only set,
rather than telling about non-existing table. 

How to repeat:
as root: SET GLOBAL read_only=1;

mysql> drop temporary table xxx;
ERROR 1290 (HY000): The MySQL server is running with the --read-only option so it cannot
execute this statement
mysql> create temporary table xxx(a int);
Query OK, 0 rows affected (0.03 sec)
mysql> drop temporary table xxx;
Query OK, 0 rows affected (0.00 sec)

Suggested fix:
check table existence before checking for readonly

Thank you for your bug report. This issue has been addressed in the documentation. The
updated documentation will appear on our website shortly, and will be included in the
next release of the relevant products.

I updated the descriptions for the read_only system variable
and the --read-only option.

See Bug #4544 for the original addition of temp table support under read_only.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/15557

ChangeSet@1.2334, 2006-11-20 17:35:23+03:00, kaa@polly.local +3 -0
  Fix for bug #22077 "DROP TEMPORARY TABLE fails with wrong error if read_only is set"
  
  Do not issue a 'read-only' error in case of DROP TEMPORARY TABLE on a non-existing
temporary table.
  Instead produce the correct "Unknown table" error or warning (in cases when the IF
EXISTS clause was specified).
  
  To a documentor: the part of the manual describing the 'read_only' system variable
should be clarified to state the following:
  "When the read_only variable is set to ON, all operations which create/update/drop
tables are rejected with the exceptions for:
  1. Any operation performed by the replication thread on a slave server
  2. Any operation performed by a user that have the SUPER privilege
  3. Any operation that creates/updates/drops only temporary tables"

Noted in 5.0.32, 5.1.15 changelogs.

For a nonexistent table, DROP TEMPORARY TABLE failed with an
incorrect error message if read_only was enabled.