Incident brief
Relation does not exist
A query referenced a table that PostgreSQL couldn't find. Usually a typo, but the table can also just be in a schema that isn't being searched.
What lands in your log
ERROR: relation "monthly_report" does not exist
In 10 seconds
- What triggers it
- Query a table name that doesn't exist anywhere in the database.
- Fix
- Fix a typo'd table name if that's the cause.
- Proof
- Reproduced on PostgreSQL 16.14 → Querying a table name that doesn't exist anywhere in the database was rejected with SQLSTATE 42P01. The session was unaffected afterward.
Fix
What to do right now
Application-level steps for this error.
- Fix a typo'd table name if that's the cause.
- If the table exists in a different schema, qualify it (schema.table) or add that schema to search_path.
- Double-check which schema a new object actually landed in, see the premium test below for how search_path decides this.
CREATE TABLE monthly_report (
report_day date PRIMARY KEY,
total bigint NOT NULL DEFAULT 0
);
INSERT INTO monthly_report(report_day, total)
VALUES (CURRENT_DATE, 1);
SELECT * FROM monthly_report;For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Resolve the exact name using the affected session's search_path and case rules; do not create a new table until you know which relation was intended.
Search path used by this session
An unqualified relation can exist in another schema and still raise 42P01.
SELECT current_setting('search_path') AS search_path,
current_schemas(true) AS resolved_schemas;Resolve the relation from the error
Replace the literal with the exact identifier; to_regclass returns NULL instead of raising when it cannot resolve it.
SELECT to_regclass('<schema_or_unqualified_relation>') AS resolved_relation;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, §5.9.3 The Schema Search Path
If there is no match in the search path, an error is reported, even if matching table names exist in other schemas in the database.Read the full section on postgresql.org →
The query against a nonexistent table
PostgreSQL searched every schema on the current search_path, found no match, and reported the exact name it looked for.Confirming the session still works
Outside an explicit transaction, the failed query didn't affect anything else, the next statement ran normally.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Query a table name that doesn't exist anywhere in the database.
- 2PostgreSQL rejects the query with SQLSTATE 42P01, naming the exact relation it couldn't find.
- 3The session itself is unaffected, the next statement runs normally.
One client: query a table name that was never created.
-- No schema needed: this error only requires querying a table that doesn't exist.
SELECT 1;SELECT * FROM monthly_report;SELECT 1 AS session_still_alive;What PostgreSQL actually returned
?column?
----------
1
(1 row)ERROR: relation "monthly_report" does not exist
LINE 1: SELECT * FROM monthly_report;
^ session_still_alive
----------------------
1
(1 row)The search_path fix was tested directly: a table that genuinely exists but sits outside the current search_path errors when referenced unqualified, then succeeds once its schema is added to search_path.
Without this
Before: the table genuinely exists, but isn't on the current search_path, the unqualified name still fails with SQLSTATE 42P01.
With this, tested
After: adding archive to search_path lets the exact same unqualified name resolve successfully.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that looks safe but can silently resolve to the wrong table: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Runbook to fix this
Runbooks for this incident
Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Understand the concept
Fix it — runbooks
Related errors
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.