Lock:transactionid

Session waiting for other session to complete the transaction. (Session is blocked).
The transactionid wait event in PostgreSQL occurs when a backend process is blocked while waiting for a specific transaction to complete.
For example, Updating the same rows of a table from multiple sessions can lead to this situation.
This is one of the more serious wait events that can significantly impact database performance.

This waitevent indicates that:
  1. One transaction is waiting for another transaction to finish (commit or abort)
  2. There is direct transaction ID dependency between sessions
  3. This typically involves row-level locking scenarios where MVCC (Multi-Version Concurrency Control) can't resolve the conflict

Why it is happening (Root Causes)

Following are common scenarios that lead to transactionid waits:
  1. Lock Contention: When Transaction A holds locks that Transaction B needs Example: Long-running UPDATE blocking another UPDATE/DELETE on same rows
  2. Foreign Key Operations: When checking referential integrity during updates/deletes
  3. Prepared Transactions: Waiting for a prepared transaction (2PC) to commit/rollback
  4. Serializable Isolation Level: In SERIALIZABLE isolation, waiting for a potentially conflicting transaction to complete
  5. VACUUM Operations: When VACUUM is blocked by long-running transactions

Performance Implications

  1. More severe than tuple waits as it involves entire transactions rather than individual rows
  2. Can lead to transaction chains where multiple sessions wait in sequence

Often indicates:

  1. Long-running transactions holding locks
  2. Application logic issues (transactions staying open too long)
  3. Insufficient vacuuming leading to transaction ID wraparound prevention