Admin fn may hang the runtime

[evenyag]

What type of bug is this?

Locking issue

What subsystems are affected?

Standalone mode, Distributed Cluster

Minimal reproduce step

1. Run the database in a container with 1 core.
2. Create a table and insert some rows into it.
3. Use select flush_table() to flush it.

Also see #4436 (comment)

What did you expect to see?

Flush is done.

What did you see instead?

The flush function hangs forever.

What operating system did you use?

Unrelated

What version of GreptimeDB did you use?

0.0.0

Relevant log output and stack trace

2024-07-29T14:29:49.385378397Z stdout F 2024-07-29T14:29:49.385189Z  INFO operator::request: Handle table manual flush request: FlushTableRequest { catalog_name: "greptime", schema_name: "public", table_name: "quod" }

[evenyag]

This may cause the chaos fuzz test timeout......
https://github.com/GreptimeTeam/greptimedb/actions/runs/10471600984/job/28999517343?pr=4591

[evenyag]

Using a function to invoke some non-computational operation is not a good idea. Datafusion doesn't support async functions or async UDF.

Also, it's inconvenient to pass flush/compaction options via the function interface. The function signature may become too complicated if there are many options.

We should implement dedicated clauses for flush/compact instead of using the admin function. For example, ClickHouse has a list of system clauses. We might also define some clauses like SYSTEM FLUSH TABLE or ADMIN FLUSH TABLE.

[waynexia]

I still don't think function/UDF is a good abstraction for such admin functionalities. And it turns out to be lots of problems in the implementation that we(except the person who implemented this) need to spend lots of time to debug, alleviate and workaround. Why would you be negative to dedicated SQL clauses @killme2008 ?

[evenyag]

After discussing with @killme2008, we can still use functions to do this. But we can add a new clause to invoke the function:

ADMIN flush_table('my_table');