bug: Optimize PURGE on Dropped Table Fails

[inviscid]

Search before asking

• [x] I had searched in the issues and found no similar issues.

Version

v1.2.786-nightly

What's Wrong?

It appears impossible to PURGE a dropped fuse table. When trying to run the PURGE command, Databend reports that the query completed successfully but when checking fuse_time_travel_size() the dropped table size doesn't change.

For tables that have not been dropped, the PURGE does seem to work.

How to Reproduce?

1. Create a fuse table
2. Load data several times to create various snapshots
3. Drop the table
4. View the size of the time travel data using fuse_time_travel_size()
5. Attempt to OPTIMIZE PURGE the table
6. Observe that the time_travel_size has not changed

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

[inviscid]

An additional observation: Dropping and recreating a table with the same name, causes there to be a Dropped table in the list of FUSE tables while another table with that same name shows as not dropped. Attempting to UNDROP the old table fails because of the name collision.

There may be an issue with Databend being able to resolve which table to PURGE when multiple versions with the same name exist.

[sundy-li]

we need vacuum command to purge the dropped tables.

set data_retention_time_in_days=3;
vacuum drop table;

BTW, it's ee feature.