password_expiration_warning_threshold

Definition PG 20 devel manual

When this parameter is greater than zero, the server will emit a WARNING upon successful password authentication if less than this amount of time remains until the authenticated role's password expires. Note that a role's password only expires if a date was specified in a VALID UNTIL clause for CREATE ROLE or ALTER ROLE. If this value is specified without units, it is taken as seconds. The default is 7 days. This parameter can only be set in the postgresql.conf file or on the server command line.

How it works

PostgreSQL describes password_expiration_warning_threshold as follows: “Threshold for password expiration warnings.” A configuration reload applies the value to the server without a full 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.

After successful password authentication, PostgreSQL warns when a role with VALID UNTIL has less than this interval remaining. Zero disables the warning; the default seven-day window is advisory and does not create, rotate, or extend credentials, and non-password authentication does not make password expiry management automatic.

Read it together with password_encryption, authentication_timeout, md5_password_warnings, hba_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 password_expiration_warning_threshold as proof of the effective value on an initialized or managed cluster.

Applying a change as though it were immediate while pg_settings reports sighup 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.