Parameter · Reporting and Logging / When to Log
log_startup_progress_interval
Time between progress updates for long-running startup operations. 0 disables progress updates.
- Default:
10s - Type: integer (ms)
- Range: 0 … max (2147483647)
- Applies: Reload
In plain words
After a crash, PostgreSQL may need minutes to sync files and replay WAL before it accepts connections. This setting makes it print a progress line every so often, so you know it is working rather than stuck.
For DBAs and operators
Introduced in PostgreSQL 15. Applies to the startup process's long operations: syncing the data directory, resetting unlogged relations, and WAL redo during crash recovery. Lines captured with a 10ms interval after an immediate shutdown:
LOG: syncing data directory (fsync), elapsed time: 0.09 s, current path: ./base/5/3599 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 0/3FECAC0 LOG: redo in progress, elapsed time: 0.40 s, current LSN: 0/79613F0 LOG: redo done at 0/DB04050 system usage: CPU: user: 0.86 s, system: 0.11 s, elapsed: 1.14 sUse the current LSN values to estimate time remaining: compare the progress rate with the end of WAL (pg_controldata or the newest file in pg_wal). Progress lines are not emitted for a standby's continuous replay (that would be endless). 0 disables them.
Support tip: "the database is not coming up after a crash" with no progress lines usually means it is still in the fsync phase on a huge data directory. Consider recovery_init_sync_method = syncfs on Linux.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then run SELECT pg_reload_conf().
See it in context
Related parameters
recovery_init_sync_method log_checkpoints checkpoint_timeout