55000ERRORTier 2 — Caution⚠️ MEDIUM confidence

object not in prerequisite state

Category: Object Not In Prerequisite StateVersions: All Postgres versions

What this means

An operation was attempted on a database object that is not in the state required to perform that operation. Common triggers include vacuuming a non-existent table, refreshing a materialized view that has not been populated, or reindexing a system catalog while the system is not in the correct state.

Why it happens

1REFRESH MATERIALIZED VIEW CONCURRENTLY on a view that has never been populated with a non-concurrent REFRESH first
2VACUUM or ANALYZE on an object that has been concurrently dropped
3Attempting to alter a sequence that is in an inconsistent state after a crash recovery
4Running certain pg_upgrade steps when the cluster is not in the expected state

How to reproduce

REFRESH MATERIALIZED VIEW CONCURRENTLY is called before the view has been initially populated.

trigger — this will ERROR

CREATE MATERIALIZED VIEW mv_summary AS
  SELECT count(*) FROM generate_series(1,10)
WITH NO DATA; -- not yet populated

REFRESH MATERIALIZED VIEW CONCURRENTLY mv_summary; -- triggers 55000

ERROR: materialized view "mv_summary" has not been populated DETAIL: Use the REFRESH MATERIALIZED VIEW command without the CONCURRENTLY option first.

Fix 1: Perform an initial non-concurrent REFRESH first

When the materialized view was created WITH NO DATA and needs its first population.

fix

-- Initial population (acquires ACCESS EXCLUSIVE lock):
REFRESH MATERIALIZED VIEW mv_summary;

-- Subsequent refreshes can be concurrent (requires unique index):
CREATE UNIQUE INDEX ON mv_summary (count);
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_summary;

Why this works

CONCURRENTLY works by building a new version of the view in the background and swapping it atomically. This requires an existing populated version to compare against. The first non-concurrent REFRESH populates the relation file in pg_class, enabling subsequent CONCURRENTLY refreshes.

What not to do

✗

Always use ACCESS EXCLUSIVE REFRESH without checking for CONCURRENTLY eligibility

Why it's wrong: ACCESS EXCLUSIVE locks block all reads on the materialized view during refresh, causing query timeouts on busy systems.

Version notes

Postgres 9.4+REFRESH MATERIALIZED VIEW CONCURRENTLY introduced. Earlier versions must use the locking non-concurrent variant.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

📚 Feature docs: https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html

📖 Further reading: REFRESH MATERIALIZED VIEW

Confidence assessment

⚠️ MEDIUM confidence

The materialized view scenario is well-documented. Other triggers for 55000 are rarer and more environment-specific. Confidence for the documented CONCURRENTLY case is HIGH; confidence for crash-recovery and pg_upgrade scenarios is MEDIUM.