## 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.

```text
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 STV_LOCKS and SVV_TRANSACTIONS 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