hosts_file

Definition PG 20 devel manual

Specifies the configuration file for host-based SSL configuration (customarily called pg_hosts.conf). This parameter can only be set at server start. See also Section 18.9.6.

How it works

PostgreSQL describes hosts_file as follows: “Sets the server's "hosts" configuration file.” The value is fixed when the server starts, so changing it requires a controlled restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster's effective setting.

The path identifies pg_hosts.conf, the server-side SNI mapping file introduced in PostgreSQL 19. When ssl_sni is enabled, hostname, /no_sni/, and wildcard entries select certificate, key, optional CA, and optional passphrase commands; an empty or missing file falls back to the ordinary postgresql.conf TLS files.

Read it together with ssl_sni, ssl_cert_file, ssl_key_file, ssl_ca_file. 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 hosts_file 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.

Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Workload guidance

OLAP: Apply the same security policy to batch drivers and long-lived ETL connections. Test clients that omit SNI, credential-expiry automation, reload behavior, and certificate-chain compatibility.

OLTP: Roll out through staged clients, validate certificate selection and expiry warnings, and monitor authentication failures. Keep a tested fallback and treat file permissions and secret rotation as part of the same change.

SMALL: Prefer a simple, documented TLS and credential policy. Do not enable multi-certificate routing without a test for every hostname and fallback path, and never weaken verification to hide configuration mistakes.