postgres error: pg_stat_statements must be loaded via shared_preload_libraries - how to enable

postgres error: pgstatstatements must be loaded via sharedpreloadlibraries - how to enable

TL;DR

pgstatstatements needs to be loaded at server start, so CREATE EXTENSION fails until you add it to sharedpreloadlibraries and restart. Edit postgresql.conf, restart, then CREATE EXTENSION. There is no way to enable it without a restart.

ERROR: pg_stat_statements must be loaded via shared_preload_libraries

Steps

1. Open postgresql.conf and set: sharedpreloadlibraries = 'pgstatstatements'. Expected: The line is present and uncommented.

2. Restart the Postgres server (reload is not enough; the library loads at postmaster start). Expected: The server comes back up with the library preloaded.

3. Create the extension in the database you want stats for: CREATE EXTENSION pgstatstatements. Expected: It creates successfully now.

4. Verify: SELECT count(*) FROM pgstatstatements. Expected: It returns a growing row count as queries run.

5. For managed databases (RDS, Cloud SQL, AlloyDB), enable it through the provider's parameter group or flags page instead of the config file; the restart is still required. Expected: Same result, done through the console or CLI.

When to use

• CREATE EXTENSION pgstatstatements fails with the preload error
• pgstatstatements views are empty because the module never loaded
• you are setting up query-level observability on a new instance

When not to use

• the extension creates but stays empty (check the database you created it in; it is per-database)
• you only need per-session stats (pgstatactivity may be enough)
• you cannot restart (use auto_explain or log-based capture as a weaker substitute)

Tool compatibility

• PostgreSQL 12 through 17
• RDS, Cloud SQL, AlloyDB via parameter groups

Variant phrasings

• "pgstatstatements sharedpreloadlibraries restart"
• "must be loaded via sharedpreloadlibraries fix"
• "enable pgstatstatements without restart"

Why it happens

pgstatstatements hooks into the executor at a level that requires it to be present before any backend starts, which is what sharedpreloadlibraries does. A plain CREATE EXTENSION loads it too late, so Postgres refuses. The restart is structural, not a bug.

Edge cases

• adding it to sharedpreloadlibraries on every node matters for replicas and standby setups too
• pgstatstatements tracks a bounded number of queries (pgstatstatements.max); busy servers with many distinct queries evict old entries
• on managed providers the parameter is often named exactly sharedpreloadlibraries in a custom parameter group

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_v4QsXjKheROA56E3Av-wOQ