@Rocky is there any way to abort or rollback a commited transaction in any version of starrocks?

In StarRocks, once a transaction is committed and has reached the

VISIBLE

status, it is considered permanent and cannot be rolled back using a simple

ROLLBACK

or

UNDO

command. This applies to both native StarRocks tables and most loading methods. However, depending on your version and table type, there are specific mechanisms to revert data or recover from an accidental commit: 1. SQL Transactions (v3.5.0 and later) StarRocks supports standard SQL transactions using

BEGIN

,

COMMIT

, and

ROLLBACK

. * During the transaction: You can use

ROLLBACK

at any point before calling

COMMIT

to undo all changes (INSERT, UPDATE, DELETE) made within that session. * After COMMIT: Once

COMMIT

is executed, the

ROLLBACK

command will no longer work for that transaction. 2. Table-Specific Rollback (Iceberg) If you are using Iceberg tables through an Iceberg Catalog, StarRocks supports true rollback to a specific point in time: * Command:

ALTER TABLE <table_name> EXECUTE rollback_to_snapshot(<snapshot_id>);

* This resets the table's state to a previous committed snapshot. 3. Shared-Data (Cloud-Native) Cluster Recovery In shared-data clusters (available in v3.0+), there are advanced recovery options: * Cluster-level Snapshots (v3.5+): You can restore the entire cluster metadata to a previous snapshot stored in object storage. * Metadata Rollback: The

ADMIN REPAIR TABLE

command can sometimes be used to roll back tablet metadata to a previous version (primarily used for disaster recovery if data files are lost). 4. Manual "Undo" for Native Tables For native StarRocks tables (Duplicate, Primary Key, etc.), there is no built-in "undo" for a committed load or DML. You must use manual methods: * Delete/Truncate: Use

DELETE FROM table WHERE ...

or

TRUNCATE TABLE

if you have a way to identify the affected rows (e.g., via a timestamp or a batch ID). * Negative Loading (Aggregate Tables): For Aggregate tables using the

SUM

function, you can load the same data with negative values to "offset" the committed transaction. * RECOVER Command: If you mistakenly dropped a table or partition after a transaction, you can use

RECOVER TABLE <name>

to restore it from the trash (default retention is 24 hours). Summary Table Feature | Supported? | Note Rollback BEFORE commit | Yes | Use

ROLLBACK;

(SQL) or

/api/transaction/rollback

(Stream Load). Rollback AFTER commit | No | For native tables, data is permanent once visible. Iceberg Rollback | Yes | Use

rollback_to_snapshot

. Time Travel Query | Yes | For Iceberg tables (

SELECT ... FOR VERSION AS OF ...

). Data Recovery | Yes | Use

RECOVER

for dropped tables/partitions. If you need to revert a specific transaction that just happened, your best course of action is typically to manually delete the affected rows using a filter that matches that specific load or DML or Load Label or timestamp. References • data_source/catalog/iceberg/iceberg_timetravel.md • knowledge/admin_and_operation/shared_data_compaction.md