Section 2 of 3 · 7 minutes

Know where a setting applies

Your goal

What you will be able to do

Distinguish settings that apply immediately, after reload, after reconnect, or only after restart.

Why this matters at work

The practical reason

A correct value can still cause an outage when it is changed with the wrong rollout method.

Learn

The idea in plain English

PostgreSQL settings have a context. Some can change in one transaction or session. Some require a configuration reload. Others require a server restart.

A value can also come from several sources, including the main configuration file, ALTER SYSTEM, a database, a role, or the current session. Inspect the source before assuming which file to edit.

Remember these points

Read the setting context before planning the change.
Read the source before editing configuration.
Test reconnect and restart requirements in a disposable environment.

See it in SQL

Read values, sources, and change context

See how important connection and memory settings are currently supplied.

SELECT
  name,
  setting,
  unit,
  context,
  source,
  pending_restart
FROM pg_settings
WHERE name IN ('max_connections', 'shared_buffers', 'work_mem')
ORDER BY name;

`context` describes how a setting may change. `pending_restart` shows whether a new value is waiting for a restart.

`source` helps find the active configuration layer. Record it before making a change so rollback targets the right place.

What you should see

Current value, unit, context, source, and pending-restart state for three important settings.

Useful words

Important terms

Configuration context: The rule that determines when and where a PostgreSQL setting can change.

Quick check · Not graded

Check your understanding

Which field shows that a changed setting still needs a restart?

Choose one answerapplication_namepending_restartcurrent_database

Your progress is saved to your signed-in account.