| Type: | enum |
| Default: | try |
| Context: | sighup |
| Restart: | false |
| Values: | [off, on, try] |
| Since: | 15 |
Whether to try to prefetch blocks that are referenced in the WAL that are not yet in the buffer pool, during recovery. Valid values are off, on and try (the default). The setting try enables prefetching only if the operating system provides the posix_fadvise function, which is currently used to implement prefetching. Note that some operating systems provide the function, but it doesn't do anything.
Prefetching blocks that will soon be needed can reduce I/O wait times during recovery with some workloads. See also the wal_decode_buffer_size and maintenance_io_concurrency settings, which limit prefetching activity.
On StackOverflow
On pgsql-hackers
- possible bug in handling of contrecords in dd38ff28ad (Fix recovery_prefetch with low maintenance_io_concurrency)
- Incorrect handling of OOM in WAL replay leading to data loss
- Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
- Add new option 'all' to pg_stat_reset_shared()
- Re: Add new option 'all' to pg_stat_reset_shared()