Skip to main content

DEPLOY.PREFLIGHT.CONCURRENT_INDEX_BLOCKER — a concurrent index build is about to wait on unrelated work

  • Category: safety
  • Severity: medium
  • Level: 0
  • Downtime class: online
  • Stability: stable
  • Suites: deploy
  • Applies to: PostgreSQL

The mechanism that surprises people​

CREATE INDEX CONCURRENTLY is the safe way to add an index, and its cost is patience: it waits for every older transaction to finish — not only the ones touching its own relation.

A long-running query in an unrelated schema delays it just as effectively as one on the table being indexed. Most people expect the opposite, which is why this has its own finding rather than being folded into the lock blocker.

Why medium rather than high​

Nothing breaks. The build does not fail and no statement errors — it sits there, holding a SHARE UPDATE EXCLUSIVE lock for as long as the oldest transaction lives. A deploy window planned for four minutes becomes forty, and the only symptom is a step that has not finished.

Compare the sibling arm at high: there a session is holding a table this migration is about to lock, and a queue forms behind it while the table stops answering.

What to do about it​

Look at what those sessions are doing before you start the deploy. Nothing here says they are wrong to be running — a long analytics query is a legitimate thing for a database to be doing. The finding says the build is about to wait on them.

The cases this cannot see​

  • It is a snapshot. A session running now may finish before the build starts waiting; one that is idle now may open a transaction a second later.
  • It counts sessions past the activity reader's threshold on any table, so it cannot say which of them the build will actually end up waiting for.