BufferPin waits

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.