Timeout: VacuumTruncate
Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed
PostgreSQL wait event dossier
ClassTimeout
Event
VacuumTruncate
VersionsPG 15-18
Evidence2 source location(s)
Official description
Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed
| PG 13 | PG 14 | PG 15 | PG 16 | PG 17 | PG 18 |
|---|---|---|---|---|---|
| — | — | ✓ | ✓ | ✓ | ✓ |
Trigger mechanism
WAIT_EVENT_VACUUM_TRUNCATE at src/backend/access/heap/vacuumlazy.c:3280 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:183. The instrumented operation is: Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed. The VacuumTruncate path deliberately waits on a timer, retry interval, throttle, or safety backoff. The latch timeout expires before work is reconsidered.
Normal or trouble?
- Normal: The wait is normal when the configured policy is intentional and useful work advances at the expected rate.
- Investigate: Investigate when the policy causes missed maintenance, recovery, backup, or latency objectives, or when a spin delay persists.
Diagnostic SQL
Sessions waiting on Timeout/VacuumTruncate
Current Timeout cohort
Lock and relation context for these sessions
Response
- Identify the GUC or function that owns the timer.
- Compare productive work with time spent delayed.
- Adjust the policy only after checking the CPU, I/O, and durability pressure it was designed to control.
Source evidence
- PostgreSQL 18.6 · src/backend/access/heap/vacuumlazy.c:3280 —
WAIT_EVENT_VACUUM_TRUNCATE - PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:183 —
VACUUM_TRUNCATE
Related controls and signals
- GUCs: [guc:autovacuum_naptime]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:oldest_transaction_age]