agent timed out waiting for redshift vacuum to finish, vacuum stuck

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 stuck

Use 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

1. Check STVLOCKS and SVVTRANSACTIONS for blockers on the table. Note any holder. Verify: lock contention is confirmed or ruled out
2. Check the table's unsorted percentage and size to estimate honest VACUUM duration. Note the estimate. Verify: the expected duration is known
3. 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
4. Wait a bounded time proportional to the estimate, rechecking progress. Note the deadline. Verify: waiting is bounded
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_4Z-pFI2OS-KCQkI7yf6aQw

Thread query: agent timed out waiting for redshift vacuum to finish, vacuum stuck

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.