# BufferPin waits

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

`BufferPin` has one core event, also named [BufferPin](buffer-pin/). 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 {#how-to-read}

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 {#diagnosis}

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 {#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.

---

Section pages:

- [BufferPin: BufferPin](/bufferpin/buffer-pin/): Waiting to acquire an exclusive pin on a buffer