agent timed out waiting for redshift vacuum to finish, vacuum stuck
Gives agents a playbook for Redshift VACUUM operations that never finish: lock contention, sizing, and bounded waits. Use when an agent waits on VACUUM past its timeout. Not for VACUUM that fails fast.
TL;DR
VACUUM is stuck waiting on a table lock or grinding through a huge unsorted table. The agent should check for lock holders and the table's unsorted ratio, wait a bounded time if progress is real, and escalate with the blocker named if it is lock contention. An agent cannot hurry a storage rewrite; it can only decide whether to keep waiting.
agent timed out waiting for redshift vacuum to finish, vacuum stuckUse this when
- An agent waits on a Redshift VACUUM that never finishes.
- The VACUUM shows no progress over multiple checks.
- The agent's timeout fires first.
Not for this skill when
- VACUUM fails fast with an error. Read the error.
- Queries are slow but VACUUM is not running. That is a different problem.
Steps
- Check STVLOCKS and SVVTRANSACTIONS for blockers on the table. Note any holder. Verify: lock contention is confirmed or ruled out
- Check the table's unsorted percentage and size to estimate honest VACUUM duration. Note the estimate. Verify: the expected duration is known
- If blocked by a lock, identify the holder and decide: wait it out or escalate to clear it. Note the decision. Verify: the block is handled deliberately
- Wait a bounded time proportional to the estimate, rechecking progress. Note the deadline. Verify: waiting is bounded
- Escalate with the table, the blocker, and the observed progress. Note the escalation. Verify: a human gets the full picture
Variant phrasings
redshift vacuum taking forever
The symptom phrasing.
redshift vacuum progress check
The monitoring search.
Compatibility: Amazon Redshift. Lock and vacuum-progress views are Redshift system tables.
Why it happens
VACUUM rewrites storage and needs exclusive locks, so it queues behind every concurrent reader and writer on the table. On a busy table the queue may never clear, and the operation waits indefinitely while the agent's clock runs out. Separately, a massively unsorted table legitimately takes hours, which is not stuck but slow. The agent's job is to distinguish the two from system views: locks mean contention, progress means patience, neither means waiting forever.
Edge cases / pitfalls
- Killing a VACUUM mid-rewrite is safe but wastes the work done. Prefer letting it finish over restarting it.
- Auto-VACUUM may already be handling the table; a manual VACUUM then queues pointlessly. Check auto-vacuum state first.
- The agent should not terminate blocking queries itself without authority. Escalate the kill decision.
- VACUUM progress views update coarsely. Sparse updates do not prove a stall; compare over long intervals.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_4Z-pFI2OS-KCQkI7yf6aQw