silent_mode

Definition PG 9.1 manual

Runs the server silently. If this parameter is set, the server will automatically run in background and disassociate from the controlling terminal. This parameter can only be set at server start.

How it works

PostgreSQL describes silent_mode as follows: “Runs the server silently.” The value is fixed when the server starts, so changing it requires a controlled restart. The atlas measures it in PG9.0–9.1; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

Silent mode was an early background-server convenience that redirected or suppressed terminal-facing output. It was removed in PostgreSQL 9.2; service managers and PostgreSQL's logging_collector, log_destination, and log_directory settings now provide explicit process and log ownership.

Read it together with logging_collector, log_destination, log_directory, log_filename. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Operational considerations

Treating the measured boot_val for silent_mode as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports postmaster context.

Changing this setting in isolation without checking the linked limits, observability, and rollback path.

Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Workload guidance

OLAP: For an upgrade or analytical estate, inventory every generated configuration before cutover. Map the old control to its successor and compare plans, throughput, WAL, or logging behavior rather than assuming the old numeric value is portable.

OLTP: Do not add this retired name to a current OLTP configuration. Translate its intent to the documented successor, test the migration under connection and write concurrency, and remove stale automation that still emits it.

SMALL: Delete the obsolete override after recording why it existed. On a small node, prefer the successor's default until measurements justify a new value; an unknown startup parameter can otherwise stop the server.