Lock: transactionid
Waiting for a transaction to finish
PostgreSQL wait event dossier
ClassLock
Event
transactionid
VersionsPG 13-18
Evidence3 source location(s)
Official description
Waiting for a transaction to finish
| PG 13 | PG 14 | PG 15 | PG 16 | PG 17 | PG 18 |
|---|---|---|---|---|---|
| ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Trigger mechanism
PG_WAIT_LOCK at src/backend/storage/lmgr/proc.c:1487 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:423. The instrumented operation is: Waiting for a transaction to finish. The lock manager could not grant the transactionid heavyweight lock immediately. ProcSleep reports the lock wait and parks the backend on the lock’s wait queue until owners release or the request is cancelled.
Normal or trouble?
- Normal: Sub-second handoff during ordinary writes or planned DDL can be normal.
- Investigate: Investigate once a user-facing wait breaches its latency objective, a blocking chain grows, or the root holder is idle in transaction.
Diagnostic SQL
Sessions waiting on Lock/transactionid
Current Lock cohort
Lock and relation context for these sessions
Response
- Build the pg_blocking_pids graph to its root.
- Inspect the root holder’s state, transaction age, and business purpose.
- Choose cancellation, timeout, or workload sequencing only after identifying the safest root action.
Source evidence
- PostgreSQL 18.6 · src/backend/storage/lmgr/proc.c:1487 —
PG_WAIT_LOCK - PostgreSQL 18.6 · src/backend/utils/activity/wait_event_names.txt:423 —
transactionid - PostgreSQL 18.6 · src/backend/utils/adt/lockfuncs.c:34 —
transactionid
Related controls and signals
- GUCs: [guc:lock_timeout] · [guc:deadlock_timeout]
- Metrics: [metric:waiting_sessions] · [metric:wait_event_share] · [metric:blocked_sessions] · [metric:locks_per_backend]