Question: Configuration
Do I need to restart Postgres after changing a setting?
Answered in the first paragraph. Last updated .
Usually not. Every setting carries a context that says how it can be changed, and only one of those values requires a restart: the settings fixed when the server process starts, such as the connection limit and the shared buffer size. Everything marked as reloadable takes effect on a configuration reload, with no downtime and no dropped connections.
Reading the answer out of the server instead of a blog post
The settings view is authoritative for the version you are running, which no external list is. Filter it by name and read the context column. Anything that needs a restart says so. Anything reloadable is applied by a reload. A few can be changed for a single session, and a few are fixed at the moment the database was created and cannot be changed at all without recreating it.
There is a second column worth knowing about, which reports whether a value has been edited in a file and is waiting for the restart that has not happened. That flag is the difference between a change that is live and a change that is merely written down, and it is the thing to check after any configuration deployment. A cluster where somebody edited a file three months ago and never restarted looks correctly configured in the file and behaves like the old value.
Reloading can be done by the server function, by the command line tool, or by a signal. All three do the same thing. A reload never drops a connection; existing sessions pick up the new value at their next opportunity, and a session that has explicitly overridden a setting for itself keeps its own value.
The part that is not about restarting at all
The harder failure is not whether the setting took effect. It is whether it took effect everywhere. A cluster with a standby has two copies of this configuration, and some settings must be at least as large on the standby as on the primary or the standby refuses to start after a failover, which is the least convenient moment to find out.
Changes made through the server rather than through the file land in an auto-configuration file that overrides the main one, so a cluster can have a value in the file, a different value overriding it, and a third value in an included fragment. Reading the file is not reading the configuration.
Configuration drift between a primary and its standby covers what to compare and how often. If the setting you are considering is the shared buffer size, the trade is less obvious than it looks, because the operating system is caching the same pages: that is double buffering.