Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Not a Bug
-
Affects Version/s: 10.0.16
-
Fix Version/s: N/A
-
Component/s: Prepared Statements
-
Labels:None
-
Environment:REHL5
Description
Hello,
After migration from MariaDB 5.5 to 10.0.16 the value of table_definition_cache have change to the table_open_cache that was set to 400 , this was a regression to the default 1024 value proposed in 5.5. and produced some unexpected new error s on the API
Prepared statement needs to be re-prepared (1615).
Raising table_definition_cache to 1024 fixed the issue.
Why the value of a cache would make queries to failed is an other question
Can this be old upstream bug http://bugs.mysql.com/bug.php?id=42041
Gliffy Diagrams
Attachments
Issue Links
- is part of
-
MDEV-4261 Use tabledef_version in TABLE_SHARE::get_table_ref_version()
-
- Open
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Why the success of the execution of a prepare statement is tied to the value of a server cache variable. For me that's a bug but i may be wrong and miss educated here !
A prepared statement needs to be re-prepared if any of its tables is ALTER-ed. For example, if you prepare SELECT * FROM t1 and somebody adds a new column to the table, then your prepared statement will have different metadata — number of columns, and it needs to be re-prepared to notice that.
There are no persistent table metadata versions in MySQL, so when a table is reopened, the server assumes that table metadata might have changed, there is no way to detect it in MySQL. That's why when you make the table definition cache smaller, and tables are pushed out of the cache more often, you'll have re-prepares more often.
So, it's not a bug.
But in MariaDB we do have a persistent table metadata version, though. If we'll use it for this, it will make spurious re-prepares go away. It is MDEV-4261.
Thanks Sergei, that all clear now
What is the bug here?