Bug Report: race condition between schema reads and table GC operation

[shlomi-noach]

Overview of the Issue

Schema reads, caused e.g. by ReloadSchema() or explicitly by VReplication upon start of new workflow (via buildColInfoMap) run into the following race condition:

1. we construct a GetSchemaRequest message
2. the schema analysis, performed by Mysqld, first lists all tables
3. then, table by table, it runs SHOW CREATE TABLE ...
4. and depending on TableSchemaOnly, also SELECT ... FROM INFORMATION_SCHEMA.COLUMNS ... to read column info for said table

However, it is possible for a table to be dropped right after step (2) and before (3) or (4), in which case the schema analysis results with an error.

Such a scenario is frequently reproduced in onlineddl_vrepl endtoend test; the trigger is for TableGC to drop the "right" table at the "right time". As it happens onlineddl_vrepl causes that scenario more often than not, in one of its PRS operations.

While the bug is not limited to GC tables, those tables are low hanging fruit. They should be ignored by the schema analysis, just as they are ignored by many other internal operations. Specifically, no one is interested in SELECTing from _vt_(HOLD|PURGE|EVAC|DROP)... tables. In fact, _vt_HOLD_* is the only table that has any potential to be restored to production, and that, too, only after RENAME. And the rest of the tables are just on the long path to getting destroyed.

And so a simple and immediate first step if for VReplication to exclude, ie ignore, all GC tables when doing schema analysis. (they are also already ignored by vplayer anyway).

Reproduction Steps

Binary Version

-

Operating System and Environment details

-

Log Fragments

No response