@Rocky - I am getting failed to handle stmt [INSERT INTO statistics.loads_history SELECT * FROM information_schema.loads WHERE load_finish_time IS NOT NULL AND load_finish_time < NOW() - INTERVAL 1 MINUTE AND load_finish_time > ( SELECT COALESCE(MAX(load_finish_time), '0001-01-01 000000') FROM statistics.loads_history); - how do I reset that?

The error you're seeing is coming from the LoadsHistorySyncer, an internal StarRocks background process that periodically moves metadata from the memory-resident

information_schema.loads

view into the persistent

_statistics_.loads_history

table for long-term storage. When this statement fails, it usually indicates that the internal

loads_history

table is in an unhealthy state (e.g., corrupted tablets, replica count mismatches after a cluster scale-in, or schema issues after an upgrade). How to "Reset" the Loads History You can reset this by dropping the internal table. StarRocks is designed to recreate these internal system tables automatically if they are missing. 1. Check the table status Verify if the table exists and if there are any obvious issues with its replicas:

sql
    SHOW CREATE TABLE _statistics_.loads_history;

2. Drop the internal table If the table is unhealthy, drop it. You may need to enable a session variable to allow operations on system-reserved names:

sql
    SET allow_system_reserved_names = true;
    DROP TABLE _statistics_.loads_history;

3. Wait for automatic recreation The

LoadsHistorySyncer

runs every 60 seconds (controlled by the FE config

loads_history_sync_interval_second

). On its next run, it will detect the table is missing and attempt to recreate it. Why this happens * Scale-in Issues: If you recently reduced the number of Backends (BEs), the internal table might still be looking for 3 replicas when only 1 or 2 BEs are available. StarRocks v3.3.6+ attempts to fix this automatically, but older versions may require a manual drop. * Upgrade Schema Mismatch: If you recently upgraded, the schema of

information_schema.loads

might have changed, causing the

INSERT INTO ... SELECT *

to fail if the old table schema doesn't match. Dropping the table allows it to be recreated with the correct schema. * Disk/Tablet Issues: If specific tablets of this internal table become corrupted or "SHUTDOWN," background inserts will fail. Note: Dropping this table will clear your historical load records (typically the last 30 days of load metadata), but it will not affect your actual data or ongoing load jobs. The

information_schema.loads

view will still contain the most recent records. References • loading/loading_introduction/troubleshooting_loading.md • using_starrocks/Cost_based_optimizer.md • sql-reference/sql-statements/cbo_stats/DROP_STATS.md • administration/management/FE_configuration.md • sql-reference/sql-statements/cbo_stats/DROP_ANALYZE.md • sql-reference/information_schema/loads.md