ALTER DATABASE ... RESET removes database-level parameter overrides, returning settings to their default values.
It deletes custom parameter settings stored in pg_db_role_setting for a specific database, forcing PostgreSQL to fall back to cluster defaults defined in postgresql.conf.
Use it after testing feature flags, lowering work_mem for heavy reports, or undoing per-database tweaks before promoting to production.
Run ALTER DATABASE dbname RESET parameter_name; The change is instant for new sessions; existing connections need reconnecting.
List them comma-separated inside parentheses: ALTER DATABASE dbname RESET (work_mem, maintenance_work_mem);
Yes—use ALTER DATABASE dbname RESET ALL; This leaves the database entirely dependent on cluster-wide settings.
Suppose you lowered random_page_cost to speed up ad-hoc analytics on the analytics database. To undo:
ALTER DATABASE analytics RESET random_page_cost;
Your staging DB ecom_stg runs with extremely low shared_buffers and effective_cache_size. Before load tests:
ALTER DATABASE ecom_stg RESET ALL;
This ensures staging mimics production defaults.
Always record current settings with pg_settings or pg_dumpall --globals-only. Schedule resets during low-traffic windows for apps that maintain persistent connections.
Connect again and query pg_settings: SELECT name, setting, source FROM pg_settings WHERE source = 'configuration file'; The parameter should no longer show database as the source.
If the value stays the same, check for role-level overrides with ALTER ROLE ... SET, or session-level SET commands inside your application pooler.
Only the database owner or a superuser can execute it, ensuring regular users cannot alter global behavior.
No, settings are scoped to the target database only. Other databases keep their own overrides.
Query pg_db_role_setting joined with pg_database to see parameter-value pairs stored at the database level.