We are using the cold data archiving feature in PolarDB for MySQL with the following configuration:

PolarDB version: 8.0.2.2.35
Archive format: CSV
Cluster topology:
- One primary (RW) node
- One read-only (RO) node

A table had previously been archived to PolarDB-managed OSS cold storage in CSV format.

The actual database and table names have been anonymized below.

To remove the table and its archived data, we followed the procedure described in the PolarDB documentation:

DROP TABLE `archive_db`.`archived_table`;

CALL dbms_oss.delete_table_file(
    'archive_db',
    'archived_table'
);

Neither operation displayed an error when it was executed. Unfortunately, the original command output was not retained.

Official documentation:

https://help.aliyun.com/en/polardb/polardb-for-mysql/user-guide/faq-6

After performing these operations, we observed the following:

- The table no longer exists in the database.
- The table no longer appears on the Space Management page.
- The corresponding storage is still visible on the Cold Data Storage page.
- Cold-storage usage continued to generate charges.

The documentation says that OSS file deletion is asynchronous and that PolarDB waits until all nodes in the cluster have stopped using the OSS files before physically deleting them.

However, it does not appear to specify:

- the normal or maximum deletion delay;
- how to inspect the asynchronous deletion task;
- how to determine which node still references the files;
- or when billing for the files stops.

My questions are:

1. Does dbms_oss.delete_table_file only submit an asynchronous deletion request, even when the procedure returns without an error?

2. How long does it normally take for archived CSV files to disappear from the Cold Data Storage page?

3. Is there a SQL view, system table, stored procedure, log, or console page that can show whether the deletion is:

   pending,
   waiting for an RW or RO node to release the files,
   running,
   completed,
   or failed?
   

4. Can an idle RO node, an existing session, a long-running query, or cached metadata keep archived files referenced after the table has been dropped?

5. When does PolarDB stop charging for the cold-storage space: when the procedure is called, when the asynchronous request is accepted, or only after the OSS files are physically deleted?

6. Are there known issues in PolarDB version 8.0.2.2.35 where archived CSV files remain after dbms_oss.delete_table_file is executed?

We are trying to determine whether this is expected asynchronous garbage-collection behavior, a failed deletion task, a console reporting delay, or a billing delay.