log_startup_progress_interval

Definition PG 18 manual

Sets the amount of time after which the startup process will log a message about a long-running operation that is still in progress, as well as the interval between further progress messages for that operation. The default is 10 seconds. A setting of 0 disables the feature. If this value is specified without units, it is taken as milliseconds. This setting is applied separately to each operation. This parameter can only be set in the postgresql.conf file or on the server command line.

For example, if syncing the data directory takes 25 seconds and thereafter resetting unlogged relations takes 8 seconds, and if this setting has the default value of 10 seconds, then a messages will be logged for syncing the data directory after it has been in progress for 10 seconds and again after it has been in progress for 20 seconds, but nothing will be logged for resetting unlogged relations.

How it works

log_startup_progress_interval defines the interval between progress updates for long-running startup operations. 0 disables progress updates. Startup processes emit periodic progress for operations such as WAL replay when they exceed the interval; zero disables these updates.

log_startup_progress_interval is a SIGHUP-context setting: a configuration reload activates the new server value without a restart; subsequent operations that consult it use the refreshed value.

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

Operational considerations

Editing log_startup_progress_interval without reloading configuration and verifying the effective value and subsequent behavior.

Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.

Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.

Changing log_startup_progress_interval globally without a rollback plan and a client or operational compatibility test.

Workload guidance

OLAP: Analytical jobs can justify richer log_startup_progress_interval telemetry, but account for long statements, large bind values, and bursty completion patterns in the log pipeline.

OLTP: Tune log_startup_progress_interval against an explicit observability question and a measured log-volume budget. Prefer selective thresholds, sampling, or role-level overrides over indiscriminate capture.

SMALL: Keep log_startup_progress_interval useful but bounded: verify disk, collector, retention, and redaction capacity before increasing detail or frequency.