VACUUM FULL rewrites a table to return space to the operating system after bloat has made ordinary VACUUM insufficient. The tempting emergency fix is dangerous: rewriting requires extra disk space, runs slowly, and takes an ACCESS EXCLUSIVE lock that makes the table unusable during the operation. section 6.7 section 7.1
Keep these operational distinctions in mind:
- Treat ordinary VACUUM and VACUUM FULL differently: ordinary VACUUM marks dead-row space for PostgreSQL to reuse, whereas VACUUM FULL returns reclaimable space to the operating system. section 6.7 section 7.1
- Avoid using VACUUM FULL on an active production table unless its locking, duration, and additional disk-space requirements are fully understood. section 6.7 section 7.1
- Prevent emergency compaction by making autovacuum more effective on write-intensive workloads instead of disabling it or weakening its settings. section 6.7
The disk-space emergency
After deleting old data, the database may still lack disk space: PostgreSQL must write WAL, and dead rows remain until vacuumed. A VACUUM FULL can release table space to the operating system, but it also needs free space for the rewrite and blocks all use of that table while running. section 7.1
ERROR: could not extend file "base/12609/16048": No space left on device HINT: Check free disk space.
Use this diagnostic listing to recognize the no-space condition that can prompt an unsafe VACUUM FULL response. section 7.1
