Details
-
New Feature
-
Status: Open (View Workflow)
-
Critical
-
Resolution: Unresolved
-
None
Description
currently REPAIR follows a very complex if/then logic, that depends on keywords that were used in the command and engine capabilities. It's roughly something like
- if USE_FRM was specified
- < FRM_VER_TRUE_VARCHAR(≈2005) && has varchar -> "too old"
- if not MyISAM or Aria or CSV -> silently ignore USE_FRM
- rename/truncate/rename
- if ALGORITHM=COPY is needed (and not FORCE/USE_FRM), use it
- otherwise, per engine:
- MyISAM run repair, QUICK or EXTENDED, or QUICK then EXTENDED
- Aria, same as MyISAM
- S3 — "Table '%-.192s' is read only"
- Archive, perform OPTIMIZE
- all other engines
- if needs upgrade: use ALTER ALGORITHM=COPY
- otherwise "The storage engine for the table doesn't support REPAIR"
- if ALGORITHM=COPY is needed but wasn't used -> "Operation failed"
So to repair a table the user might need to run with various keywords, read the engine-dependent output, and repeat REPAIR variants in a specific order.
We should consider changing it to something like
- if the table is marked corrupted
- repair it (in-engine of via the ALTER fallback)
- if the table needs upgrading
- upgrade it (ALTER ALGORITHM=COPY)
- if that fails — go to step one (but no more than once)
FORCE here will mean "force/pretend table to be corrupted", that is, do the first step even if the table is not corrupted. USE_FRM basically works as above but with an error instead of ignoring, and nobody should use it anyway. If the table is neither corrupted or needs upgrading REPAIR can do nothing (as above) or force a repair (for backward compatibility).
With this logic the REPAIR will be "just fix the table" command, it'll do everything that is needed in whatever order that's needed to make the table fixed and up-to-date. It will automatically determine what needs to be done depending on the state of the table and engine capabilities.
Attachments
Issue Links
- is blocked by
-
-
- Closed
-