The essentials

Quick reference

One focused task per row. Jump to the related section for complete, working examples.

UseSyntaxExamples
Show one effective valueSHOW statement_timeout;View examples
Read a setting safelySELECT current_setting('app.request_id', true);View examples
Inspect source and contextSELECT name, setting, unit, context, source, pending_restart FROM pg_settings WHERE name = 'shared_buffers';View examples
Set for this sessionSET SESSION statement_timeout = '30s';View examples
Set for one transactionSET LOCAL lock_timeout = '2s';View examples
Set through a functionSELECT set_config('app.request_id', 'req-9f2a', true);View examples
Reset one overrideRESET statement_timeout;View examples
Set a database defaultALTER DATABASE appdb SET statement_timeout = '60s';View examples
Set a role defaultALTER ROLE report_reader SET default_transaction_read_only = ON;View examples
Set a role-database defaultALTER ROLE report_reader IN DATABASE appdb SET statement_timeout = '15s';View examples
Write a cluster overrideALTER SYSTEM SET log_min_duration_statement = '1s';View examples
Reload configurationSELECT pg_reload_conf();View examples
Validate file entriesSELECT sourcefile, sourceline, name, setting, error FROM pg_file_settings WHERE error IS NOT NULL OR NOT applied;View examples
Find pending restartsSELECT name, setting, sourcefile FROM pg_settings WHERE pending_restart ORDER BY name;View examples
Delegate one settingGRANT SET ON PARAMETER statement_timeout TO app_operator;View examples
Use a trusted search pathSET LOCAL search_path = pg_catalog, app;View examples
Inspect capacity settingsSELECT name, setting, unit, source FROM pg_settings WHERE name IN ('work_mem', 'max_connections', 'max_wal_senders');View examples

PostgreSQL configuration is a precedence stack rather than one file: startup options, configuration files, ALTER SYSTEM, database and role defaults, connection parameters, and session or transaction overrides can all contribute. Safe changes begin by inspecting a parameter's context and source, choose the narrowest scope, validate file parsing, distinguish reloads from restarts, and record a rollback. Treat planner, memory, timeout, logging, security, and replication settings as production changes that require workload testing and version-specific review.

Step by step

Detailed examples

01

Inspect the effective value, source, unit, and change context

SHOW and current_setting report what this session sees, not necessarily the cluster-wide default. pg_settings adds the source, implicit unit, allowed range, reset value, source file, context, and pending_restart flag. Context determines whether a setting is internal, startup-only, reloadable, fixed at backend start, superuser-controlled, or user-settable. Record server_version_num and the full row before changing anything because names, defaults, units, enum values, and contexts can differ across PostgreSQL major versions and managed services.

Build a version-aware change record
SELECT current_setting('server_version_num') AS server_version_num;

SELECT name, setting, unit, vartype, context, source, sourcefile, sourceline,
       min_val, max_val, enumvals, boot_val, reset_val, pending_restart
FROM pg_settings
WHERE name IN (
  'statement_timeout',
  'work_mem',
  'shared_buffers',
  'max_wal_senders'
)
ORDER BY name;

Note: pg_settings.setting uses the parameter's implicit unit. Preserve unit-qualified values in automation to avoid ambiguous conversions.

Back to quick reference ↑
02

Use transaction-local overrides for bounded work

SET SESSION lasts until reset or disconnect after its transaction commits, while SET LOCAL lasts only until the current transaction ends and has no useful effect outside a transaction block. Both changes roll back to a savepoint established before them. set_config provides the same model for dynamic parameter names and values. Prefer SET LOCAL for per-request timeouts or memory because pooled connections can leak session settings to the next borrower; pool reset commands help but are not a substitute for correct scope.

Bound one maintenance transaction
BEGIN READ ONLY;
SET LOCAL statement_timeout = '2min';
SET LOCAL work_mem = '256MB';

SELECT customer_id, count(*) AS event_count
FROM app.events
WHERE occurred_at >= TIMESTAMPTZ '2026-08-01 00:00:00+00'
GROUP BY customer_id
ORDER BY event_count DESC
LIMIT 100;

COMMIT;

Note: work_mem can be consumed by multiple plan nodes and parallel workers. Choose a value from workload tests, not from one query's apparent input size.

Back to quick reference ↑
03

Apply defaults at the narrowest persistent scope

ALTER DATABASE SET and ALTER ROLE SET establish defaults for future sessions; the combined ALTER ROLE IN DATABASE form is narrower and overrides each separately. Existing sessions keep their current defaults. These commands write catalog state and are physically replicated with the cluster, but role and database definitions are not automatically recreated by logical replication. Avoid using defaults as an authorization control because users may override user-context settings. Audit role membership and connection pools when predicting which default wins.

Constrain a reporting identity in one database
ALTER ROLE report_reader
IN DATABASE appdb
SET default_transaction_read_only = on;

ALTER ROLE report_reader
IN DATABASE appdb
SET statement_timeout = '15s';

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting AS s
JOIN pg_roles AS r ON r.oid = s.setrole
JOIN pg_database AS d ON d.oid = s.setdatabase
WHERE r.rolname = 'report_reader';

Note: Reconnect as the target role to verify effective values. Read-only mode is a safety default, not a complete privilege boundary.

Back to quick reference ↑
04

Separate reloadable changes from restart-only changes

ALTER SYSTEM writes postgresql.auto.conf and cannot run inside a transaction or function because the filesystem change is not transactional. A reload applies sighup-context settings and updates eligible existing backends after their current command; postmaster-context settings need a controlled restart, while backend-context settings affect only new sessions. postgresql.auto.conf overrides postgresql.conf, so an old ALTER SYSTEM entry can mask configuration management. Keep one owner for configuration, use explicit RESET for rollback, and never edit postgresql.auto.conf concurrently with ALTER SYSTEM.

Stage a reloadable logging change with rollback
-- Run outside an explicit transaction.
ALTER SYSTEM SET log_min_duration_statement = '1s';
SELECT pg_reload_conf();

SELECT name, setting, context, source, sourcefile, pending_restart
FROM pg_settings
WHERE name = 'log_min_duration_statement';

-- Rollback procedure:
ALTER SYSTEM RESET log_min_duration_statement;
SELECT pg_reload_conf();

Note: ALTER SYSTEM success only confirms that the file was written. Verify the effective source and value after reload on the intended server.

Back to quick reference ↑
05

Validate file contents before reload and verify every node afterward

pg_file_settings parses current configuration-file contents and reports syntax errors, invalid values, and overridden entries before they are necessarily active. It is superuser-only by default because paths and settings are sensitive. A single syntax error can prevent file settings from applying. After reload or restart, query pg_settings rather than assuming the file won; repeat checks on primary, standbys, and failover candidates because configuration files are not WAL-replicated and independent nodes can drift.

Preflight and postflight a configuration deployment
SELECT sourcefile, sourceline, seqno, name, setting, applied, error
FROM pg_file_settings
WHERE error IS NOT NULL OR NOT applied
ORDER BY sourcefile, sourceline;

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

Note: An unapplied row without an error can simply be overridden by a later entry. Review seqno and every include file before removing it.

Back to quick reference ↑
06

Delegate configuration capability parameter by parameter

Superusers and roles granted ALTER SYSTEM on a parameter can persist cluster changes; roles granted SET can change restricted runtime parameters in allowed scopes. Parameter privileges, introduced in PostgreSQL 15, should be granted narrowly and reviewed during upgrades. Settings can weaken security or stability: search_path affects object resolution, logging can expose data, memory values multiply per operation, timeouts alter availability, and replication settings affect durability. Do not treat allow_alter_system=off as a security boundary, and protect pg_read_all_settings because source paths and values may reveal operational details.

Delegate and audit a single bounded capability
GRANT SET ON PARAMETER statement_timeout TO app_operator;

SELECT p.parname AS parameter_name,
       pg_get_userbyid(a.grantee) AS grantee,
       a.privilege_type, a.is_grantable
FROM pg_parameter_acl AS p
CROSS JOIN LATERAL aclexplode(p.paracl) AS a
WHERE p.parname = 'statement_timeout';

REVOKE SET ON PARAMETER statement_timeout FROM app_operator;

Note: pg_parameter_acl and parameter GRANT require PostgreSQL 15 or later. Gate migrations by server_version_num when supporting older releases.

Back to quick reference ↑
07

Model multiplicative resource cost and topology-wide consistency

work_mem can be consumed by multiple plan nodes, parallel workers, and concurrent sessions; max_connections drives backend and memory pressure; WAL, checkpoint, replication, and autovacuum settings interact rather than tuning independently. Test representative concurrency, not one EXPLAIN. Runtime configuration is cluster-local: physical standbys have their own files and startup parameters, while ALTER ROLE and ALTER DATABASE catalog values follow physical WAL but not logical publications. Keep failover-safe settings synchronized where required, preserve deliberate role differences, and rehearse rollback under load.

Review high-impact settings as one capacity surface
SELECT name, setting, unit, context, source, pending_restart
FROM pg_settings
WHERE name IN (
  'max_connections', 'shared_buffers', 'work_mem', 'maintenance_work_mem',
  'max_worker_processes', 'max_wal_senders', 'max_replication_slots',
  'wal_level', 'synchronous_commit'
)
ORDER BY name;

Note: Do not copy values mechanically between primary and standby. Recovery, archival, read-only workload, and promotion requirements can justify documented differences.

Back to quick reference ↑

Sources and further reading

References

Authoritative documentation used to verify and expand this cheat sheet.

  1. PostgreSQL Global Development GroupPostgreSQL: Setting Parameterspostgresql.org
  2. PostgreSQL Global Development GroupPostgreSQL: SETpostgresql.org
  3. PostgreSQL Global Development GroupPostgreSQL: ALTER SYSTEMpostgresql.org
  4. PostgreSQL Global Development GroupPostgreSQL: pg_settingspostgresql.org
  5. PostgreSQL Global Development GroupPostgreSQL: pg_file_settingspostgresql.org

Help us improve

Found a typo or missing example?

Tell us what would make this cheat sheet clearer, more complete, or more useful.

Share feedback