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

[7 Sep 2006 11:00] Domas Mituzas
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
[4 Oct 2006 17:52] Paul Dubois
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.
[5 Oct 2006 0:52] Kolbe Kegel
See Bug #4544 for the original addition of temp table support under read_only.
[20 Nov 2006 14:36] Bugs System
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:


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"
[21 Dec 2006 20:19] Paul Dubois
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.