ssl_passphrase_command_supports_reload

ssl_passphrase_command_supports_reload is the PostgreSQL setting that controls whether “ssl_passphrase_command” is called during server reload.

Note

Fact — official short description: “Controls whether “ssl_passphrase_command” is called during server reload.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valuesighup: Takes effect after configuration reload
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueConnections and Authentication / SSL: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG11
Present in	PG11–19 Beta 3
Removed in	No
Introduction commit	`8a3d9425290f` — Add ssl_passphrase_command setting
Commit date	2018-02-26
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG11–19 Beta 3	`off`	—	off

How it works

ssl_passphrase_command_supports_reload decides whether ssl_passphrase_command may be invoked during configuration reload when a replacement SSL key needs a passphrase. When it is off, the command is ignored during reload and PostgreSQL does not reload the SSL configuration if a passphrase is required.

The setting has SIGHUP context and affects replacement TLS material used by new handshakes; existing TLS sessions are not renegotiated. It should be on only when the helper is noninteractive, reliably available, and safe to invoke in the running server environment.

On Windows this setting must be on, because the Windows process model causes every connection to perform a configuration reload. That platform requirement overrides the usual Unix-oriented choice to keep a TTY-dependent helper startup-only.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Enable this only after ssl_passphrase_command is proven noninteractive, idempotent, fast, and available during reload; otherwise a certificate refresh can fail operationally.
OLAP	Use the same reload capability across workload classes so certificate rotation behavior is predictable on every node.
Small nodes	On Windows this setting must be on. On Unix, leave it off only when reload-time passphrase retrieval is unnecessary; if unattended rotation is required, enable it after testing the helper in the server environment.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG11–19 Beta 3 unmodified; OLAP: PG11–19 Beta 3 unmodified; CRIT: PG11–19 Beta 3 unmodified; TINY: PG11–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Setting it to off on Windows, where PostgreSQL requires it to be on because each connection performs a configuration reload.
Enabling reload support while the passphrase helper is interactive, slow, unavailable, or unsafe to invoke repeatedly.
Assuming a reload renegotiates existing sessions; replacement TLS material affects new handshakes only.
Failing to inspect server logs after reload; if passphrase retrieval fails, PostgreSQL keeps the previous SSL configuration.

ssl · ssl_cert_file · ssl_key_file · ssl_ca_file · ssl_crl_file · ssl_min_protocol_version