Repository navigation
Conversation
| statement.execute("create database async_drop_db"); | ||
| statement.execute("use async_drop_db"); | ||
| statement.execute("create table drop_target (device string tag, reading int32)"); | ||
| statement.execute("drop table drop_target"); | ||
|
|
||
| try (final ResultSet resultSet = | ||
| statement.executeQuery( | ||
| "select procedure_id, state, progress " | ||
| + "from information_schema.drop_table_procedures " | ||
| + "where database = 'async_drop_db' and table_name = 'drop_target'")) { | ||
| assertTrue(resultSet.next()); | ||
| assertTrue(resultSet.getLong(1) >= 0); | ||
| assertFalse(resultSet.getString(2).isEmpty()); | ||
| assertFalse(resultSet.getString(3).isEmpty()); | ||
| assertFalse(resultSet.next()); | ||
| } |
There was a problem hiding this comment.
The procedure may finish before the query starts.
There was a problem hiding this comment.
Updated the IT to wait for completion and verify the retained SUCCESS result, removing the redundant query immediately after DROP TABLE. This covers both a drop that finishes before the first query and one that is still running. The unit test checks the active deletion stage while execution is held by a CountDownLatch, so that assertion does not depend on deletion timing.
| try (final ResultSet resultSet = | ||
| statement.executeQuery( | ||
| "select procedure_id, state, progress, error_message " | ||
| + "from information_schema.drop_table_procedures " | ||
| + "where database = 'async_drop_db' and table_name = 'drop_target'")) { | ||
| assertTrue(resultSet.next()); | ||
| assertTrue(resultSet.getLong(1) >= 0); | ||
| assertEquals("SUCCESS", resultSet.getString(2)); | ||
| assertEquals("SUCCESS", resultSet.getString(3)); | ||
| Assert.assertNull(resultSet.getString(4)); | ||
| assertFalse(resultSet.next()); | ||
| } |
There was a problem hiding this comment.
Are the results stored even after the procedure finishes? How long and how many?
There was a problem hiding this comment.
Yes. The view includes both active drops and completed results retained by the executor's existing completed-procedure cleaner. Retention uses procedure_completed_evict_ttl (60 seconds by default, measured from the procedure's last update); the cleaner runs every procedure_completed_clean_interval (30 seconds by default), so an expired record disappears on a subsequent cleanup. There is no separate count limit: all drop results within that retention window are included. This PR reuses the existing procedure store and cleanup policy rather than adding a separate history store. I also documented the shared TTL retention on getDropTableProcedures().
| dropTableWorkerThreads = new CopyOnWriteArrayList<>(); | ||
| dropTableWorkerThreads.add( | ||
| new WorkerThread(threadGroup, dropTableScheduler, "DropTableProcedureWorker-")); |
There was a problem hiding this comment.
Better to delay the init until the first DropTable comes.
There was a problem hiding this comment.
Changed this to lazy initialization: init()/startWorkers() no longer create a DROP TABLE worker when there is no drop to run. The first scheduled drop creates one worker; recovered runnable/failed drops create it during recovery and start it in startWorkers(). Initialization, startup, and shutdown share the lifecycle lock so concurrent first submissions cannot create or start it twice. Added regression coverage for concurrent first drops, recovery/restart, completed drops not creating a worker, DROP VIEW routing, and regular procedures progressing while a drop is blocked.
2 participants
Description
DROP TABLEnow acknowledges the request after the ConfigNode validates the table and persists its procedure. The deletion continues in the background, so the client does not wait for data and device removal.Procedure execution
DROP VIEWbehavior.Visibility and progress
SHOW TABLESwhile its metadata is inPRE_DELETE;SHOW TABLES DETAILSshows that status.information_schema.drop_table_procedureswithdatabase,table_name,procedure_id,state,progress, anderror_message.progressreports the current deletion stage. Recently completed procedures remain visible until the existing procedure retention period expires.Verification
DropTableProcedureTestandClusterSchemaInfoTest(9 tests passed).IoTDBTableIT#testAsyncDropTableProgress,IoTDBTableIT#testManageTable, andIoTDBDatabaseIT#testInformationSchemapassed in a test cluster.origin/master.This PR has:
Key changed/added classes (or packages if there are too many classes) in this PR
ProcedureManager,ProcedureExecutor, andDropTableProcedure: asynchronous submission, worker isolation, and stage reporting.InformationSchemaandInformationSchemaContentSupplierFactory: progress table and query results.