Skip to content

This is the multi-page printable view of this section. .

Return to the regular view of this page.

BufferPin waits

A backend needs an exclusive buffer pin while another backend still holds one.

BufferPin has one core event, also named BufferPin. It means PostgreSQL needs exclusive access to a shared buffer but another backend still pins that page so it cannot be removed or structurally changed.

Treat persistence as suspicious

Pins are normal and short-lived while executors inspect pages. A sustained exclusive-pin wait is unusual and can come from another session holding a cursor open, an executor paused on a page, or concurrent index work that needs to delete/recycle the page.

  • Normal: isolated, sub-second samples during scans or index maintenance.
  • Watch: the same foreground session remains on BufferPin for more than one second.
  • Urgent: many sessions queue, index cleanup/DDL cannot advance, or a cursor-owning session is idle while holding the pin.

What to inspect

  1. Identify the waiting query and its relation locks.
  2. Look for long-running cursors, idle in transaction, and executor sessions touching the same relation.
  3. Correlate the onset with VACUUM, index deletion/recycling, DDL, or long scans.
  4. Preserve the holder’s query and transaction context before cancelling anything.

Common misreads

  • A buffer pin is not a heavyweight lock and has no direct owner row in pg_locks.
  • shared_buffers size does not make a held pin disappear.
  • The waiter may be vacuum/index maintenance while the application session holding the pin looks harmless.

1 - BufferPin: BufferPin

Waiting to acquire an exclusive pin on a buffer
PostgreSQL wait event dossier
ClassBufferPin EventBufferPin VersionsPG 13-18 Evidence2 source location(s)

Official description

Waiting to acquire an exclusive pin on a buffer

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

Trigger mechanism

WAIT_EVENT_BUFFER_PIN at src/backend/storage/buffer/bufmgr.c:5819 is the grep-verified reporting path. The public identity/resource is mapped at src/backend/utils/activity/wait_event_names.txt:286. The instrumented operation is: Waiting to acquire an exclusive pin on a buffer. The buffer manager needs an exclusive pin, but another backend still holds a pin on the same shared buffer. It sleeps until the last conflicting pin is released.

Normal or trouble?

  • Normal: An isolated sub-second sample can occur during scans or index maintenance.
  • Investigate: Treat a wait beyond one second as suspicious, especially when a cursor or idle transaction may keep the page pinned.

Diagnostic SQL

Sessions waiting on BufferPin/BufferPin 
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'BufferPin'
  AND wait_event = 'BufferPin'
ORDER BY query_age DESC NULLS LAST;
Current BufferPin cohort 
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'BufferPin'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
Lock and relation context for these sessions 
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'BufferPin'
  AND a.wait_event = 'BufferPin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

Response

  1. Preserve the waiting query and relation context.
  2. Find long cursors and idle-in-transaction sessions touching the same relation.
  3. Cancel only after identifying the safest holder or maintenance victim.

Source evidence

Related controls and signals