Fix: pg_stat_statements Must Be Loaded via shared_preload_libraries

ERROR: pg_stat_statements must be loaded via "shared_preload_libraries" (SQLSTATE 55000, object_not_in_prerequisite_state) is raised when you query the pg_stat_statements view but the extension's library was not loaded at server start. Its sibling, ERROR: relation "pg_stat_statements" does not exist (42P01), means the opposite half is missing: the library may be loaded, but CREATE EXTENSION was never run in the database you are connected to. Working pg_stat_statements requires both.

What These Errors Mean

The extension has two independent parts. The shared library (pg_stat_statements.so) hooks into the executor and allocates shared memory for its counters - that allocation can only happen at server startup, which is why the library must be listed in shared_preload_libraries and why adding it requires a restart, not a reload. The SQL objects (the view and functions) are installed per database by CREATE EXTENSION pg_stat_statements. CREATE EXTENSION succeeds even when the library is not preloaded, so you can end up with a view that exists but errors on every query - the "must be loaded" case. See the full pg_stat_statements guide for how the module works once running.

Common Causes

1. shared_preload_libraries was edited but the server was only reloaded, not restarted - the setting only takes effect at startup.
2. The library was never added at all; CREATE EXTENSION worked, so the view exists but errors when queried.
3. The library is preloaded but CREATE EXTENSION was never run, producing relation "pg_stat_statements" does not exist.
4. The extension was created in a different database - it is per-database, and monitoring tools often connect to postgres while you created it in your app database (or vice versa).
5. The edit went to the wrong postgresql.conf, or a later shared_preload_libraries line (or an include file) overrides it.
6. On managed services, the parameter change was applied to the wrong parameter group, or the instance was never rebooted after the change.

Fix on Self-Hosted PostgreSQL

1. Add the library to postgresql.conf (find the live file with SHOW config_file;):

   shared_preload_libraries = 'pg_stat_statements'
   

   If other libraries are already listed, append with a comma: 'pg_partman_bgw,pg_stat_statements'.

2. Restart the server. A reload is not enough:

   sudo systemctl restart postgresql
   # or: pg_ctl restart -D /path/to/data
   

3. Verify the library is loaded:

   SHOW shared_preload_libraries;
   

4. Create the extension in each database you will query it from:

   CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
   

5. Confirm it works:

   SELECT count(*) FROM pg_stat_statements;
   

   A row count (even a small one) means collection is live.

Fix on Managed Services

• Amazon RDS and Aurora PostgreSQL: on PostgreSQL 11+ engines the library is preloaded by default, so usually CREATE EXTENSION pg_stat_statements; is all you need. If you still get the "must be loaded" error, your instance uses a custom parameter group without it: edit the group's shared_preload_libraries to include pg_stat_statements, apply it to the instance, and reboot - it is a static parameter, so the change waits for a reboot.
• Supabase: enabled out of the box; if you dropped it, re-run CREATE EXTENSION pg_stat_statements; from the SQL editor or the dashboard's extensions page.
• Google Cloud SQL: shared_preload_libraries is not an exposed flag; the service loads the library itself. Run CREATE EXTENSION pg_stat_statements; in the target database. If you see the error here, you are almost certainly connected to a database where the extension was not created rather than facing a preload problem.

Verify the Full Chain

SHOW shared_preload_libraries;                     -- must include pg_stat_statements
SELECT extname, extversion FROM pg_extension
WHERE extname = 'pg_stat_statements';              -- must return a row in THIS database
SELECT current_database();                         -- confirm you are where you think
SELECT count(*) FROM pg_stat_statements;           -- the end-to-end test

If step two returns nothing while step one shows the library, run CREATE EXTENSION; if step one is empty, go back to the restart.

Catch Broken Query Monitoring Before You Need It

The worst time to discover pg_stat_statements is misconfigured is during an incident, when you reach for query statistics that were never being collected. NeverBlink provides AI-powered observability for PostgreSQL alongside Elasticsearch, ClickHouse, and Kafka - it verifies that pg_stat_statements is loaded and collecting on every connected cluster, then builds continuous slow-query analysis on top of it, correlating regressions with deploys and plan changes. Connect your Postgres cluster to make sure the data is there when you need it.

Frequently Asked Questions

Q: Why does CREATE EXTENSION succeed but querying the view fail?
A: CREATE EXTENSION only installs the SQL view and functions; it does not load the library into the server. Querying the view calls into the library, which fails with 55000 if it was not preloaded at startup.

Q: Can I load pg_stat_statements without restarting PostgreSQL?
A: No. The library allocates shared memory, which only happens at server start, so shared_preload_libraries changes require a full restart. LOAD 'pg_stat_statements'; in a session does not help for the same reason.

Q: I enabled everything but pg_stat_statements is missing in another database. Why?
A: Statistics collection is server-wide, but the view is installed per database. Run CREATE EXTENSION pg_stat_statements; in each database you want to query it from - each one sees the full server-wide data.

Q: Does DROP EXTENSION stop the collection overhead?
A: No. As long as the library is in shared_preload_libraries it keeps collecting and holding shared memory. To fully disable it, set pg_stat_statements.track = 'none' or remove the library and restart.

Related Reading

• pg_stat_statements: The Definitive Guide: configuration, columns, and the queries to run once it works.
• PostgreSQL Slow Query Log: the complementary per-statement logging approach.
• PostgreSQL Relation Does Not Exist: the general 42P01 error beyond this extension.
• PostgreSQL Object Not in Prerequisite State (55000): the SQLSTATE class this error belongs to.
• Diagnosing Slow Queries in PostgreSQL: what to do with the statistics once they flow.