Write-Ahead Log

• 1: archive_cleanup_command
• 2: archive_command
• 3: archive_library
• 4: archive_mode
• 5: archive_timeout
• 6: checkpoint_completion_target
• 7: checkpoint_flush_after
• 8: checkpoint_segments
• 9: checkpoint_timeout
• 10: checkpoint_warning
• 11: commit_delay
• 12: commit_siblings
• 13: fsync
• 14: full_page_writes
• 15: max_wal_size
• 16: min_wal_size
• 17: recovery_end_command
• 18: recovery_prefetch
• 19: recovery_target
• 20: recovery_target_action
• 21: recovery_target_inclusive
• 22: recovery_target_lsn
• 23: recovery_target_name
• 24: recovery_target_time
• 25: recovery_target_timeline
• 26: recovery_target_xid
• 27: restore_command
• 28: summarize_wal
• 29: synchronous_commit
• 30: wal_buffers
• 31: wal_compression
• 32: wal_decode_buffer_size
• 33: wal_init_zero
• 34: wal_level
• 35: wal_log_hints
• 36: wal_recycle
• 37: wal_skip_threshold
• 38: wal_summary_keep_time
• 39: wal_sync_method
• 40: wal_writer_delay
• 41: wal_writer_flush_after

1 - archive_cleanup_command

Identity

Lifecycle

Default history

How it works

Sets the shell command that will be executed at every restart point. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

At every restartpoint during archive recovery, PostgreSQL expands %r to the oldest WAL file still needed for a restartable recovery and runs this command. pg_archivecleanup is the usual implementation, but deleting from an archive shared by several standbys can strand another consumer.

Monitor and change archive_cleanup_command together with archive_mode, archive_command, archive_library. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Running destructive cleanup against an archive shared by other standbys or restore jobs.
• Misreading %r as the last replayed file; it is the earliest file needed to keep recovery restartable.
• Using a command that is not idempotent when a restartpoint repeats or an archive file is already absent.
• Assuming a reload executes the command immediately; it runs at recovery restartpoints.
• Letting shell quoting or an unexpected archive path turn cleanup into deletion outside the intended archive.

Related parameters

archive_mode · archive_command · archive_library · archive_timeout · restore_command · recovery_end_command

References

• PostgreSQL 19 Beta 3 — archive_cleanup_command
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - archive_command

Identity

Lifecycle

Default history

How it works

Sets the shell command that will be called to archive a WAL file. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The archiver expands %p to the source path and %f to the WAL file name, and considers exit status zero a durable success. A nonzero result is retried; a false success allows PostgreSQL to recycle the only local copy and silently breaks the archive chain.

Monitor and change archive_command together with archive_mode, archive_library, archive_timeout. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Returning success before the archive copy is durable or verified.
• Failing to quote %p/%f safely in a shell command.
• Letting repeated failures fill pg_wal and stop the server.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

archive_mode · archive_library · archive_timeout · archive_cleanup_command · restore_command · recovery_end_command

References

• PostgreSQL 19 Beta 3 — archive_command
• PostgreSQL 19 release notes
• Machine-readable GUC export

3 - archive_library

Identity

Lifecycle

Default history

How it works

Sets the library that will be called to archive a WAL file. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

A nonempty library selects an archive module through its _PG_archive_module_init callback instead of a shell command. archive_command and archive_library are alternative implementations; changing either is reloadable, while archive_mode must already be active.

Monitor and change archive_library together with archive_mode, archive_command, archive_timeout. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Configuring both a library and expecting archive_command to run as a fallback.
• Loading untrusted in-process archive code.
• Treating module success as proof that restores work.
• Reloading to a new module without verifying backlog processing, failure reporting, and rollback behavior.
• Letting repeated module failures retain WAL until pg_wal fills, without an archive-lag alert.

Related parameters

archive_mode · archive_command · archive_timeout · archive_cleanup_command · restore_command · recovery_end_command

References

• PostgreSQL 19 Beta 3 — archive_library
• PostgreSQL 19 release notes
• Machine-readable GUC export

4 - archive_mode

Identity

Lifecycle

Default history

How it works

When enabled, PostgreSQL runs the WAL archiver and submits each completed segment to archive_command or, in versions that provide it, archive_library before that segment can be recycled. The mode is separate from the command or library, so the archive destination logic can be reloaded while archiving remains enabled.

The on and always modes behave the same during normal primary operation. In recovery or standby mode, on does not archive received WAL, while always also archives segments restored from an archive or received through streaming replication.

Enabling the mode does not prove that an archive is healthy or recoverable. A command that fails causes WAL to accumulate in pg_wal; a command that falsely reports success can create an unrecoverable archive chain. Point-in-time recovery also requires a suitable base backup and tested restore procedure.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Enabling archive_mode with an empty or failing command and letting pg_wal fill.
• Using a command such as /bin/true, which reports success while breaking the recoverable WAL chain.
• Assuming archive_mode is reloadable even though changing it requires a server restart.
• Treating WAL archiving as a substitute for a base backup and restore test.
• Using always with a shared archive without duplicate-safe, race-free handling.

Related parameters

archive_command · archive_library · archive_timeout · wal_level · restore_command · max_wal_size

References

• PostgreSQL 19 Beta 3 — archive_mode
• PostgreSQL 18: Continuous Archiving and PITR
• PostgreSQL 18: Continuous Archiving in Standby
• PostgreSQL 18: pg_stat_archiver
• PostgreSQL 19 release notes
• Machine-readable GUC export

5 - archive_timeout

Identity

Lifecycle

Default history

How it works

Sets the amount of time to wait before forcing a switch to the next WAL file. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

When no natural segment switch occurs within the interval, PostgreSQL forces one so the current partial segment can be archived. It does not make WAL records durable sooner, and very small values waste archive space because archived segment files retain full segment size.

Monitor and change archive_timeout together with archive_mode, archive_command, archive_library. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating it as a commit-durability timeout.
• Choosing a tiny interval and multiplying archive storage by mostly empty full-size segments.
• Assuming forced switches solve a slow or failed archiver.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

archive_mode · archive_command · archive_library · archive_cleanup_command · restore_command · recovery_end_command

References

• PostgreSQL 19 Beta 3 — archive_timeout
• PostgreSQL 19 release notes
• Machine-readable GUC export

6 - checkpoint_completion_target

Identity

Lifecycle

Default history

How it works

PostgreSQL throttles checkpoint writes so that they are expected to finish after this fraction of the available interval. The available interval ends at the next timed checkpoint or sooner if WAL volume forces a checkpoint, so this is a pacing target rather than a fixed duration.

A larger fraction generally smooths checkpoint I/O over more time. A smaller fraction finishes writes faster, producing a higher I/O rate followed by an idle gap; the official documentation discourages reducing it for that reason.

Values too close to 1 leave little room for final synchronization and other checkpoint work. PostgreSQL’s historical default change from 0.5 to 0.9 is material when comparing otherwise identical configurations across major versions.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Interpreting the value as seconds rather than a fraction.
• Assuming a lower value reduces total I/O instead of concentrating it.
• Setting 1.0 and leaving no margin for checkpoint completion overhead.
• Ignoring early volume-triggered checkpoints from max_wal_size.
• Overlooking the default change at PostgreSQL 14.

Related parameters

checkpoint_timeout · max_wal_size · checkpoint_flush_after · checkpoint_warning · shared_buffers

References

• PostgreSQL 19 Beta 3 — checkpoint_completion_target
• PostgreSQL 18: WAL Configuration
• PostgreSQL 18: pg_stat_checkpointer
• PostgreSQL 19 release notes
• Machine-readable GUC export

7 - checkpoint_flush_after

Identity

Lifecycle

Default history

How it works

Number of pages after which previously performed writes are flushed to disk. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

Checkpoint writes are periodically handed to the operating system for writeback after this much data, smoothing the final sync and reducing dirty-cache bursts. Zero disables these intermediate flush requests; the best value is operating-system and storage dependent.

Monitor and change checkpoint_flush_after together with checkpoint_warning, checkpoint_timeout, checkpoint_completion_target. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the raw value as bytes even though an unqualified value is measured in database blocks.
• Setting it too small and increasing writeback calls and I/O fragmentation.
• Setting it too large and losing the intended smoothing before the checkpoint sync phase.
• Confusing writeback hints with a durability guarantee; fsync and wal_sync_method still define persistence.
• Copying a value across operating systems or filesystems without measuring checkpoint latency and dirty-page behavior.

Related parameters

checkpoint_warning · checkpoint_timeout · checkpoint_completion_target · max_wal_size · min_wal_size · archive_cleanup_command

References

• PostgreSQL 19 Beta 3 — checkpoint_flush_after
• PostgreSQL 19 release notes
• Machine-readable GUC export

8 - checkpoint_segments

Identity

Lifecycle

Default history

How it works

PostgreSQL describes checkpoint_segments as follows: “Sets the maximum distance in log segments between automatic WAL checkpoints.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.4; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

This was the pre-9.5 checkpoint volume control: once accumulated WAL approached the configured number of segments, PostgreSQL requested an automatic checkpoint. PostgreSQL 9.5 replaced it with max_wal_size, whose soft byte-size budget works with checkpoint_timeout and checkpoint_completion_target rather than exposing a segment count.

Read it together with max_wal_size, checkpoint_timeout, checkpoint_completion_target, wal_segment_size. 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.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.4; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for checkpoint_segments 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.
• Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Related parameters

max_wal_size · checkpoint_timeout · checkpoint_completion_target · wal_segment_size · min_wal_size

References

• PostgreSQL 9.4 — checkpoint_segments
• Machine-readable GUC export

9 - checkpoint_timeout

Identity

Lifecycle

Default history

How it works

An automatic checkpoint is considered after checkpoint_timeout, but max_wal_size can force one earlier. If no WAL has been written since the preceding checkpoint, PostgreSQL can skip the timed checkpoint, so this setting is a maximum scheduling interval rather than a promise of periodic physical work.

Longer intervals usually reduce checkpoint frequency and full-page-write amplification, while increasing the amount of WAL that crash recovery may need to replay. Shorter intervals bound that replay horizon more tightly but increase dirty-page flushing and post-checkpoint full-page images.

Checkpoint records also constrain restartpoints on standbys. This parameter should not be used to set a WAL-archive recovery point objective; archive_timeout is the control intended to force segment switches for low-WAL systems.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming a checkpoint occurs exactly every configured interval even on an idle system.
• Forgetting that max_wal_size can trigger a checkpoint earlier.
• Using checkpoint_timeout instead of archive_timeout to bound archive delay.
• Increasing it without allowing for a longer crash-recovery replay horizon.
• Reducing it so far that full-page writes and checkpoint I/O dominate.

Related parameters

max_wal_size · checkpoint_completion_target · checkpoint_warning · archive_timeout · full_page_writes · checkpoint_flush_after

References

• PostgreSQL 19 Beta 3 — checkpoint_timeout
• PostgreSQL 18: WAL Configuration
• PostgreSQL 19 release notes
• Machine-readable GUC export

10 - checkpoint_warning

Identity

Lifecycle

Default history

How it works

Sets the maximum time before warning if checkpoints triggered by WAL volume happen too frequently. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

This parameter only emits a log warning when WAL-volume checkpoints occur closer together than the threshold. It does not delay checkpoints; frequent warnings normally point to max_wal_size being too small for the WAL generation rate.

Monitor and change checkpoint_warning together with checkpoint_flush_after, checkpoint_timeout, checkpoint_completion_target. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the warning threshold as a control that delays or throttles checkpoints.
• Setting zero and silencing evidence of WAL-volume checkpoints.
• Raising the threshold instead of investigating WAL rate, max_wal_size, and requested-checkpoint frequency.
• Setting checkpoint_warning above checkpoint_timeout and expecting time-based checkpoints to produce this warning.

Related parameters

checkpoint_flush_after · checkpoint_timeout · checkpoint_completion_target · max_wal_size · min_wal_size · archive_cleanup_command

References

• PostgreSQL 19 Beta 3 — checkpoint_warning
• PostgreSQL 19 release notes
• Machine-readable GUC export

11 - commit_delay

Identity

Lifecycle

Default history

How it works

Sets the delay in microseconds between transaction commit and flushing WAL to disk. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

A backend that is about to flush commit WAL may wait this many microseconds so concurrent commits can join the same durable flush. The delay is considered only when at least commit_siblings other transactions are active, trading individual latency for possible group-commit efficiency.

Monitor and change commit_delay together with commit_siblings, synchronous_commit, wal_writer_delay. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Setting a delay while commit_siblings prevents it from being reached under the real concurrency level.
• Reading the value as milliseconds even though the unit is microseconds.
• Increasing average group-commit throughput while violating p95 or p99 commit-latency objectives.
• Expecting a delay when the commit path does not need to flush WAL.
• Changing commit_delay without measuring it together with commit_siblings and WALSync waits.

Related parameters

commit_siblings · synchronous_commit · wal_writer_delay · wal_sync_method · fsync · full_page_writes

References

• PostgreSQL 19 Beta 3 — commit_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - commit_siblings

Identity

Lifecycle

Default history

How it works

Sets the minimum number of concurrent open transactions required before performing “commit_delay”. It can be changed at session scope, so different sessions may observe different behavior.

This is the concurrency gate for commit_delay, counted from other active transactions when a commit flush is needed. It is not a count of commits already waiting and has no useful effect while commit_delay is zero.

Monitor and change commit_siblings together with commit_delay, synchronous_commit, wal_writer_delay. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Tuning it while commit_delay is zero, in which case the threshold has no effect.
• Treating it as a count of commits already waiting rather than other active transactions.
• Setting the gate too low and adding latency during ordinary moderate concurrency.
• Applying a session-level experiment globally without comparing commit latency and WALSync behavior.

Related parameters

commit_delay · synchronous_commit · wal_writer_delay · wal_sync_method · fsync · full_page_writes

References

• PostgreSQL 19 Beta 3 — commit_siblings
• PostgreSQL 19 release notes
• Machine-readable GUC export

13 - fsync

Identity

Lifecycle

Default history

How it works

Forces synchronization of updates to disk. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

When on, PostgreSQL issues durability barriers so WAL and data ordering survive an operating-system or power failure. Turning it off may improve write benchmarks, but a crash can leave corruption that crash recovery cannot repair; re-enabling it does not retroactively synchronize earlier unsafe writes.

Monitor and change fsync together with data_sync_retry, restart_after_crash, recovery_init_sync_method. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Disabling it on persistent data and assuming UPS or RAID cache alone is sufficient.
• Re-enabling it after unsafe operation and assuming earlier writes became durable.
• Benchmarking only clean shutdowns instead of power-loss recovery.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

data_sync_retry · restart_after_crash · recovery_init_sync_method · full_page_writes · wal_sync_method · synchronous_commit

References

• PostgreSQL 19 Beta 3 — fsync
• PostgreSQL 19 release notes
• Machine-readable GUC export

14 - full_page_writes

Identity

Lifecycle

Default history

How it works

Writes full pages to WAL when first modified after a checkpoint. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

After each checkpoint, the first change to a data page logs a complete page image, preventing torn-page recovery from combining old and new sectors. The extra WAL is concentrated after checkpoints and is affected by wal_compression; disabling it is unsafe unless the storage stack provides an equivalent atomic-page guarantee.

Monitor and change full_page_writes together with data_sync_retry, restart_after_crash, recovery_init_sync_method. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Disabling it without an end-to-end atomic-page guarantee.
• Confusing its WAL-volume cost with logging every page on every change.
• Ignoring the post-checkpoint full-page-image burst.
• Assuming a reload retroactively protects WAL records that were generated while full_page_writes was off.
• Benchmarking with it disabled without an end-to-end crash, recovery, and torn-page test.

Related parameters

data_sync_retry · restart_after_crash · recovery_init_sync_method · fsync · wal_sync_method · synchronous_commit

References

• PostgreSQL 19 Beta 3 — full_page_writes
• PostgreSQL 19 release notes
• Machine-readable GUC export

15 - max_wal_size

Identity

Lifecycle

Default history

How it works

The checkpointer starts an automatic checkpoint when checkpoint_timeout expires or when WAL growth is about to exceed max_wal_size, whichever happens first. More frequent checkpoints write dirty buffers more often and also cause more full-page images after each checkpoint.

max_wal_size is not a disk quota. WAL can exceed it under heavy write load, during recovery, when archiving is slow or failing, when wal_keep_size retains files, or when a replication slot still needs old WAL.

A larger value usually reduces requested checkpoints and checkpoint-related write churn, but reserves a longer WAL replay horizon after a crash and requires more pg_wal headroom. min_wal_size controls the lower recycling floor; it does not turn max_wal_size into a hard ceiling.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating max_wal_size as a hard cap on pg_wal usage.
• Raising it to conceal a failed archiver or an abandoned replication slot.
• Lowering it without checking full-page-image volume and checkpoint latency.
• Ignoring that a bare numeric value is interpreted in megabytes.
• Tuning it independently of checkpoint_timeout and checkpoint_completion_target.

Related parameters

min_wal_size · checkpoint_timeout · checkpoint_completion_target · checkpoint_warning · wal_keep_size · max_slot_wal_keep_size

References

• PostgreSQL 19 Beta 3 — max_wal_size
• PostgreSQL 18: WAL Configuration
• PostgreSQL 18: pg_stat_checkpointer
• PostgreSQL 19 release notes
• Machine-readable GUC export

16 - min_wal_size

Identity

Lifecycle

Default history

How it works

Sets the minimum size to shrink the WAL to. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

Below this floor, checkpoint recycling keeps old segment files ready for reuse instead of removing them. It is a retained/recycled space floor, not a cap; archive failures, replication slots, wal_keep_size, and max_wal_size can all make pg_wal much larger.

Monitor and change min_wal_size together with max_wal_size, wal_keep_size, wal_segment_size. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Reading it as a maximum pg_wal size.
• Sizing it without wal_segment_size rounding and burst rate.
• Ignoring archive/slot retention that can exceed both min_wal_size and max_wal_size.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

max_wal_size · wal_keep_size · wal_segment_size · checkpoint_timeout · checkpoint_completion_target · checkpoint_flush_after

References

• PostgreSQL 19 Beta 3 — min_wal_size
• PostgreSQL 19 release notes
• Machine-readable GUC export

17 - recovery_end_command

Identity

Lifecycle

Default history

How it works

Sets the shell command that will be executed once at the end of recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

PostgreSQL runs this shell command once when archive recovery finishes or a standby is promoted. %r expands to the last restart-point file name; command failure is logged but must not be treated as a transactional post-promotion hook.

Monitor and change recovery_end_command together with archive_mode, archive_command, archive_library. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the shell command as a transactional promotion hook whose failure rolls recovery back.
• Misreading %r and deleting WAL still needed by another recovery consumer.
• Using non-idempotent external side effects without accounting for promotion and recovery retries.
• Assuming a reload executes the command; it runs once when archive recovery ends.
• Embedding credentials or unsafe shell expansion in a command executed by the PostgreSQL service account.

Related parameters

archive_mode · archive_command · archive_library · archive_timeout · archive_cleanup_command · restore_command

References

• PostgreSQL 19 Beta 3 — recovery_end_command
• PostgreSQL 19 release notes
• Machine-readable GUC export

18 - recovery_prefetch

Identity

Lifecycle

Default history

How it works

Prefetch referenced blocks during recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

During recovery, PostgreSQL can issue read-ahead advice for blocks identified by WAL before replay needs them. try enables it only when the operating system supports the required advice; wal_decode_buffer_size and maintenance_io_concurrency bound how far and how much it can prefetch.

Monitor and change recovery_prefetch together with wal_decode_buffer_size, maintenance_io_concurrency, effective_io_concurrency. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming try always enables prefetch even when the operating system lacks the required read-ahead advice.
• Increasing look-ahead without considering wal_decode_buffer_size and maintenance_io_concurrency.
• Letting recovery prefetch compete with queries on a hot standby for cache and I/O queue depth.
• Benchmarking sequential recovery only, where block prefetch may provide little benefit.

Related parameters

wal_decode_buffer_size · maintenance_io_concurrency · effective_io_concurrency · shared_buffers · archive_cleanup_command · archive_command

References

• PostgreSQL 19 Beta 3 — recovery_prefetch
• PostgreSQL 19 release notes
• Machine-readable GUC export

19 - recovery_target

Identity

Lifecycle

Default history

How it works

Set to “immediate” to end recovery as soon as a consistent state is reached. The value is fixed when the server starts, so changing it requires a restart.

The only accepted value is immediate, which stops targeted recovery at the first consistent point—normally the end of an online base backup. It is mutually exclusive with the LSN, name, time, and XID target selectors.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Setting immediate together with an LSN, name, time, or XID selector.
• Confusing the first consistent point after an online backup with the desired business recovery point.
• Leaving immediate in a normal standby configuration and ending recovery unexpectedly.
• Starting without recovery.signal and assuming the target will control crash recovery.
• Assuming success when the required WAL chain never reaches a consistent point.

Related parameters

recovery_target_time · recovery_target_xid · recovery_target_lsn · recovery_target_name · recovery_target_inclusive · recovery_target_action

References

• PostgreSQL 19 Beta 3 — recovery_target
• PostgreSQL 19 release notes
• Machine-readable GUC export

20 - recovery_target_action

Identity

Lifecycle

Default history

How it works

Selects what PostgreSQL does after it reaches a configured recovery target. The value is read when recovery starts.

pause leaves recovery paused for inspection, promote ends recovery and opens the server for normal service, and shutdown stops the server at the target. pause requires hot_standby for query inspection.

The setting has no effect without a stopping target. With shutdown, recovery.signal is not removed, so an unchanged restart reaches the target and shuts down again; remove or change the recovery configuration deliberately after validation.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Expecting an action when no stopping target is configured.
• Using pause with hot_standby disabled and expecting to inspect the database with queries.
• Using promote before the recovered state has been verified.
• Using shutdown and restarting with recovery.signal and the same target still present.
• Treating shutdown as permanent removal of later WAL; the next start still replays from the last checkpoint to the target.

Related parameters

recovery_target · recovery_target_time · recovery_target_lsn · recovery_target_inclusive · recovery_target_timeline · hot_standby

References

• PostgreSQL 19 Beta 3 — recovery_target_action
• PostgreSQL 19 release notes
• Machine-readable GUC export

21 - recovery_target_inclusive

Identity

Lifecycle

Default history

How it works

Chooses which side of an exact recovery boundary is retained. The value is read when targeted recovery starts.

on stops just after and includes the target LSN, commit time, or XID; off stops just before and excludes it. The setting applies only to recovery_target_lsn, recovery_target_time, and recovery_target_xid.

It has no effect on immediate or named restore-point targets. Select the boundary from identified WAL/business evidence and validate recovered rows and transactions, not only the displayed timestamp or LSN.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Expecting it to affect immediate or named restore-point targets.
• Selecting on/off without identifying the exact boundary transaction or WAL record.
• Assuming equal timestamps imply one deterministic commit boundary.
• Validating only the reported replay position instead of recovered application data.
• Leaving the value in a reusable recovery template without documenting the intended side of the boundary.

Related parameters

recovery_target_lsn · recovery_target_time · recovery_target_xid · recovery_target_action · recovery_target_timeline · restore_command

References

• PostgreSQL 19 Beta 3 — recovery_target_inclusive
• PostgreSQL 19 release notes
• Machine-readable GUC export

22 - recovery_target_lsn

Identity

Lifecycle

Default history

How it works

Sets the LSN of the write-ahead log location up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

Recovery replays up to a pg_lsn location, with recovery_target_inclusive selecting the side of the boundary. The LSN must lie on the chosen recovery timeline and be reachable from the base backup’s WAL chain.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Using an LSN from a different cluster or a timeline not descended from the base backup.
• Setting another recovery target selector at the same time.
• Choosing inclusive without identifying which WAL record must be included.
• Requesting an LSN beyond the available archive/streaming WAL and getting an unreachable target.
• Comparing LSNs as ordinary decimal numbers instead of pg_lsn values.

Related parameters

recovery_target · recovery_target_time · recovery_target_xid · recovery_target_name · recovery_target_inclusive · recovery_target_action

References

• PostgreSQL 19 Beta 3 — recovery_target_lsn
• PostgreSQL 19 release notes
• Machine-readable GUC export

23 - recovery_target_name

Identity

Lifecycle

Default history

How it works

Sets the named restore point up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

Recovery stops at a restore point previously recorded by pg_create_restore_point(). Restore-point names are meaningful only if the corresponding WAL record is present on the selected timeline.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Naming a restore point whose WAL record is absent from the selected timeline.
• Assuming recovery_target_inclusive changes a named restore-point boundary.
• Setting another recovery target selector at the same time.
• Mistyping a case-sensitive restore-point name and making the target unreachable.
• Creating a business label without recording the cluster, timeline, and base-backup relationship.

Related parameters

recovery_target · recovery_target_time · recovery_target_xid · recovery_target_lsn · recovery_target_inclusive · recovery_target_action

References

• PostgreSQL 19 Beta 3 — recovery_target_name
• PostgreSQL 19 release notes
• Machine-readable GUC export

24 - recovery_target_time

Identity

Lifecycle

Default history

How it works

Sets the time stamp up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

Recovery compares transaction commit records with this timestamp; numeric UTC offsets or full time-zone names avoid abbreviation ambiguity. recovery_target_inclusive selects whether commits exactly at the boundary are replayed.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Using an ambiguous time-zone abbreviation instead of a numeric offset or full zone name.
• Assuming one wall-clock timestamp uniquely identifies a business transaction.
• Setting another recovery target selector at the same time.
• Choosing inclusive on/off without identifying the exact boundary commit.
• Requesting a time outside the reachable WAL range or on the wrong timeline.

Related parameters

recovery_target · recovery_target_xid · recovery_target_lsn · recovery_target_name · recovery_target_inclusive · recovery_target_action

References

• PostgreSQL 19 Beta 3 — recovery_target_time
• PostgreSQL 19 release notes
• Machine-readable GUC export

25 - recovery_target_timeline

Identity

Lifecycle

Default history

How it works

Specifies the timeline history that recovery follows. The value is read at server start for the recovery run.

latest follows the newest timeline found in the archive, current stays on the timeline current when the base backup was taken, and an explicit decimal or 0x-prefixed hexadecimal ID selects a particular branch. A timeline can be selected with or without an earlier stopping target.

The chosen timeline must descend from the base backup and its history/WAL files must be available. This setting selects a branch; it does not itself choose a transaction boundary or promote the server.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Using latest when a deliberate re-recovery must stay on an older branch.
• Using current when the required WAL exists only on a descendant timeline.
• Selecting a timeline not descended from the base backup.
• Failing to retain the timeline history file and corresponding WAL.
• Treating timeline selection as a stopping target or promotion command.

Related parameters

recovery_target · recovery_target_time · recovery_target_lsn · recovery_target_action · restore_command · primary_conninfo

References

• PostgreSQL 19 Beta 3 — recovery_target_timeline
• PostgreSQL 19 release notes
• Machine-readable GUC export

26 - recovery_target_xid

Identity

Lifecycle

Default history

How it works

Sets the transaction ID up to which recovery will proceed. The value is fixed when the server starts, so changing it requires a restart.

The target is a commit record for the named transaction ID, not a simple numeric ordering of all transactions: XIDs are assigned at start and can commit out of order. recovery_target_inclusive controls whether that target transaction is included.

At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, and recovery_target_xid may be set; timeline, inclusive, and action are modifiers. Rehearse from the same base backup through a complete WAL chain—an unreachable target makes targeted recovery fail.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming numeric XID order equals commit order; XIDs are assigned when transactions start.
• Using an XID copied from another cluster or unrelated timeline.
• Setting another recovery target selector at the same time.
• Choosing inclusive without deciding whether the target transaction itself must be present.
• Treating an XID as a globally unique business identifier across wraparound and clusters.

Related parameters

recovery_target · recovery_target_time · recovery_target_lsn · recovery_target_name · recovery_target_inclusive · recovery_target_action

References

• PostgreSQL 19 Beta 3 — recovery_target_xid
• PostgreSQL 19 release notes
• Machine-readable GUC export

27 - restore_command

Identity

Lifecycle

Default history

How it works

Sets the shell command that will be called to retrieve an archived WAL file. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

During archive recovery PostgreSQL expands %f to the requested file and %p to its destination. Success must mean the exact file was copied durably; a normal not-found result must be nonzero so recovery can try streaming or pg_wal, while shell quoting must resist unusual paths.

Monitor and change restore_command together with archive_mode, archive_command, archive_library. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Returning zero for a missing or wrong WAL file.
• Failing to quote %f and %p safely.
• Using an archive that can return a segment from the wrong timeline or cluster.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

archive_mode · archive_command · archive_library · archive_timeout · archive_cleanup_command · recovery_end_command

References

• PostgreSQL 19 Beta 3 — restore_command
• PostgreSQL 19 release notes
• Machine-readable GUC export

28 - summarize_wal

Identity

Lifecycle

Default history

How it works

Starts the WAL summarizer process to enable incremental backup. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The WAL summarizer records which blocks changed over WAL ranges so pg_basebackup can construct incremental backups. It can run on a primary or standby, but cannot summarize WAL generated at wal_level=minimal.

Monitor and change summarize_wal together with wal_summary_keep_time, wal_level, archive_mode. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Enabling it with wal_level=minimal and expecting usable summary files.
• Treating WAL summaries as a WAL archive or a backup by themselves.
• Turning the summarizer off and expecting wal_summary_keep_time cleanup to continue.
• Taking an incremental backup without checking summarizer progress and summary coverage.

Related parameters

wal_summary_keep_time · wal_level · archive_mode · max_wal_size · archive_cleanup_command · archive_command

References

• PostgreSQL 19 Beta 3 — summarize_wal
• PostgreSQL 19 release notes
• Machine-readable GUC export

29 - synchronous_commit

Identity

Lifecycle

Default history

How it works

All modes except off wait for the transaction’s WAL to be flushed locally. With off, success can be returned before local durable flush; a crash can lose recent acknowledged transactions, but recovery remains transactionally consistent and does not introduce the corruption risk associated with fsync = off.

When synchronous_standby_names selects synchronous standbys, remote_write waits for receipt and an operating-system write on a standby, on waits for a durable standby flush, and remote_apply waits for replay and query visibility. local waits only for local durable flush. Without a selected synchronous standby, the remote modes add no remote guarantee.

The effective mode is the value in force when a transaction commits. Applications can use SET LOCAL for one transaction, allowing critical and replaceable work to use different durability policies on the same server.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Equating synchronous_commit = off with fsync = off; the former risks recent data loss, not structural corruption.
• Expecting remote_write, on, or remote_apply to wait remotely when no synchronous standby is selected.
• Using remote_write while assuming the standby is durable across an operating-system crash.
• Allowing an unavailable synchronous standby to stall commits without an HA response plan.
• Leaking a session-level SET through a connection pool instead of using SET LOCAL or reset discipline.

Related parameters

synchronous_standby_names · fsync · wal_writer_delay · wal_sync_method · commit_delay · wal_level

References

• PostgreSQL 19 Beta 3 — synchronous_commit
• PostgreSQL 18: Asynchronous Commit
• PostgreSQL 18: Synchronous Replication
• PostgreSQL 19 release notes
• Machine-readable GUC export

30 - wal_buffers

Identity

Lifecycle

Default history

How it works

Sets the number of disk-page buffers in shared memory for WAL. The value is fixed when the server starts, so changing it requires a restart.

The automatic -1 value chooses about 1/32 of shared_buffers, bounded below and by one WAL segment. The buffer absorbs WAL records before writes; too little can add WALWrite pressure during bursts, while oversized allocation consumes startup shared memory without replacing durable flushes.

Monitor and change wal_buffers together with fsync, full_page_writes, wal_sync_method. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Reading -1 as a negative allocation rather than automatic sizing.
• Forgetting that the automatic choice is based on shared_buffers and capped at one WAL segment.
• Reading an unqualified positive value as bytes rather than WAL blocks; very small positives are raised to the minimum.
• Allocating a large manual buffer without evidence of WALInsert/WALWrite pressure.
• Expecting more WAL buffers to replace durable flushes or improve a storage-bound WALSync path.

Related parameters

fsync · full_page_writes · wal_sync_method · synchronous_commit · wal_writer_delay · wal_writer_flush_after

References

• PostgreSQL 19 Beta 3 — wal_buffers
• PostgreSQL 19 release notes
• Machine-readable GUC export

31 - wal_compression

Identity

Lifecycle

Default history

How it works

Compresses full-page writes written in WAL file with specified method. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

Compression applies to full-page images produced by full_page_writes, backup, or hint logging, not to every WAL record. pglz is built in; lz4/zstd availability depends on the build, and replay pays decompression CPU in exchange for lower WAL volume.

Monitor and change wal_compression together with full_page_writes, wal_log_hints, wal_level. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Expecting compression to affect every WAL record rather than full-page images.
• Selecting lz4 or zstd on a server build that does not provide that method.
• Ignoring compression CPU on the primary and decompression CPU during replay.
• Changing a privileged session value and assuming other sessions or future connections inherited it.
• Comparing WAL bytes without controlling checkpoint frequency and full_page_writes activity.

Related parameters

full_page_writes · wal_log_hints · wal_level · wal_buffers · commit_delay · commit_siblings

References

• PostgreSQL 19 Beta 3 — wal_compression
• PostgreSQL 19 release notes
• Machine-readable GUC export

32 - wal_decode_buffer_size

Identity

Lifecycle

Default history

How it works

Buffer size for reading ahead in the WAL during recovery. The value is fixed when the server starts, so changing it requires a restart.

Recovery scans this far ahead in decoded WAL to discover future block references for prefetch. It is a restart-time memory/lead limit, not a logical-decoding output buffer, and only helps when recovery_prefetch and the storage workload benefit.

Monitor and change wal_decode_buffer_size together with recovery_prefetch, maintenance_io_concurrency, effective_io_concurrency. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.
• Ignoring interactions with checkpoints, replication slots, or archive failure.
• Reloading a restart-context value and assuming it became active.

Related parameters

recovery_prefetch · maintenance_io_concurrency · effective_io_concurrency · shared_buffers · archive_cleanup_command · archive_command

References

• PostgreSQL 19 Beta 3 — wal_decode_buffer_size
• PostgreSQL 19 release notes
• Machine-readable GUC export

33 - wal_init_zero

Identity

Lifecycle

Default history

How it works

Writes zeroes to new WAL files before first use. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

With on, newly created WAL segments are zero-filled, which preallocates blocks on many filesystems. Copy-on-write filesystems may turn that work into unnecessary allocation and fragmentation; off still creates a correctly sized file by writing its last byte.

Monitor and change wal_init_zero together with wal_recycle, wal_segment_size, min_wal_size. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Disabling zero-fill on a conventional filesystem and moving allocation stalls into peak WAL creation.
• Keeping zero-fill on copy-on-write storage without measuring allocation and fragmentation cost.
• Assuming an apparently sparse file means PostgreSQL changed wal_segment_size.
• Changing a session value and expecting already-created WAL segments to be rewritten.

Related parameters

wal_recycle · wal_segment_size · min_wal_size · max_wal_size · commit_delay · commit_siblings

References

• PostgreSQL 19 Beta 3 — wal_init_zero
• PostgreSQL 19 release notes
• Machine-readable GUC export

34 - wal_level

Identity

Lifecycle

Default history

How it works

Sets the level of information written to the WAL. The value is fixed when the server starts, so changing it requires a restart.

minimal logs only crash-recovery needs and is incompatible with archiving/streaming modes that require replica data; replica supports physical replication and archive recovery; logical adds logical-decoding information. Changing level requires restart and may change WAL volume.

Monitor and change wal_level together with wal_compression, full_page_writes, wal_log_hints. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Selecting minimal while expecting archiving, streaming replication, or logical decoding.
• Raising it without budgeting extra WAL and restart downtime.
• Lowering it while slots/subscriptions still depend on the higher level.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

wal_compression · full_page_writes · wal_log_hints · wal_buffers · max_wal_senders · max_replication_slots

References

• PostgreSQL 19 Beta 3 — wal_level
• PostgreSQL 19 release notes
• Machine-readable GUC export

35 - wal_log_hints

Identity

Lifecycle

Default history

How it works

Writes full pages to WAL when first modified after a checkpoint, even for a non-critical modification. The value is fixed when the server starts, so changing it requires a restart.

When data checksums are off, this forces full-page WAL for the first hint-bit change after a checkpoint, giving pg_rewind the block-change safety it needs. With checksums enabled, equivalent hint logging already occurs, so the setting adds no further effect.

Monitor and change wal_log_hints together with wal_compression, full_page_writes, wal_level. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming it logs every hint update rather than the first page image after a checkpoint.
• Turning it on but not completing the restart before relying on pg_rewind.
• Forgetting that checksums already force the relevant hint WAL behavior.
• Confusing pg_settings base units with human-readable configuration units.
• Benchmarking throughput without a crash-recovery and archive-restore test.

Related parameters

wal_compression · full_page_writes · wal_level · wal_buffers · max_wal_senders · max_replication_slots

References

• PostgreSQL 19 Beta 3 — wal_log_hints
• PostgreSQL 19 release notes
• Machine-readable GUC export

36 - wal_recycle

Identity

Lifecycle

Default history

How it works

Recycles WAL files by renaming them. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

With on, PostgreSQL renames no-longer-needed WAL segments for future use rather than creating new files. Reuse is usually cheaper, but on copy-on-write storage fresh allocation can perform better and avoid preserving extents.

Monitor and change wal_recycle together with wal_init_zero, wal_segment_size, min_wal_size. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming recycled renames are always faster than new allocation on copy-on-write storage.
• Disabling recycling without measuring segment creation latency during WAL bursts.
• Expecting a session change to alter files already recycled or removed.
• Treating recycling as a WAL retention limit rather than a file-reuse policy.

Related parameters

wal_init_zero · wal_segment_size · min_wal_size · max_wal_size · commit_delay · commit_siblings

References

• PostgreSQL 19 Beta 3 — wal_recycle
• PostgreSQL 19 release notes
• Machine-readable GUC export

37 - wal_skip_threshold

Identity