[MDEV-28218] Spider: thread hang/deadlock as result of INSTALL PLUGIN and DROP TABLE Created: 2022-04-02 Updated: 2023-12-07 Resolved: 2023-10-06 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Plugins, Server, Storage Engine - Spider |
| Affects Version/s: | 10.5, 10.6, 10.9, 10.10, 10.11, 11.0, 11.1 |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Roel Van de Paar | Assignee: | Yuchen Pei |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | deadlock, regression-10.5, thread_hang | ||
| Issue Links: |
|
||||||||||||||||
| Description |
|
Scenario: simply execute the following SQL in some automated fashion (copy/paste into CLI for example):
In some instances (timing dependent), this will result in:
Using CLI in another session shows the issue;
i.e. mysql.spider_table is still being created, even though the INSTALL PLUGIN had already returned as completed/finished. Likely present in 10.4+. Discovered in 10.9 |
| Comments |
| Comment by Nayuta Yanagisawa (Inactive) [ 2022-04-03 ] |
|
Roel I agree with your proposal. I believe that it is highly likely that the fix for |
| Comment by Yuchen Pei [ 2023-05-07 ] |
|
This looks like it could be a duplicate of
|
| Comment by Yuchen Pei [ 2023-05-26 ] |
|
Indeed, this is caused by the server immidiately executing the drop table statement, without waiting for the spider to finish initialisation. The assumption is that plugin initialisation is done synchronously. Spider breaks this assumption. Here the deadlock is different from those of We can make spider comply with the assumption, by making its initialisation synchronous (i.e. Roel's proposal), or we can patch the current async arrangement. We will continue using |
| Comment by Roel Van de Paar [ 2023-06-05 ] |
|
Bug confirmed present in 10.5-11.1 (EOL versions not tested). Bug apparently not present in 10.4, so seems to be a 10.5 regression. |
| Comment by Yuchen Pei [ 2023-10-06 ] |
|
Fix for spider init bugs are tracked in |