EC
55000
PostgreSQLERRORNotableObject Not In Prerequisite StateMEDIUM confidence

object not in prerequisite state

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
  1. 1REFRESH MATERIALIZED VIEW CONCURRENTLY on a view that has never been populated with a non-concurrent REFRESH first
  2. 2VACUUM or ANALYZE on an object that has been concurrently dropped
  3. 3Attempting to alter a sequence that is in an inconsistent state after a crash recovery
  4. 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
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

expected output

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

Fix

Perform an initial non-concurrent REFRESH first

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

Perform an initial non-concurrent REFRESH first
-- 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

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.

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All PostgreSQL errors