Resource Usage

• 1: autovacuum_work_mem
• 2: backend_flush_after
• 3: bgwriter_delay
• 4: bgwriter_flush_after
• 5: bgwriter_lru_maxpages
• 6: bgwriter_lru_multiplier
• 7: commit_timestamp_buffers
• 8: dynamic_shared_memory_type
• 9: effective_io_concurrency
• 10: file_copy_method
• 11: file_extend_method
• 12: hash_mem_multiplier
• 13: huge_page_size
• 14: huge_pages
• 15: io_combine_limit
• 16: io_max_combine_limit
• 17: io_max_concurrency
• 18: io_max_workers
• 19: io_method
• 20: io_min_workers
• 21: io_worker_idle_timeout
• 22: io_worker_launch_interval
• 23: io_workers
• 24: logical_decoding_work_mem
• 25: maintenance_io_concurrency
• 26: maintenance_work_mem
• 27: max_files_per_process
• 28: max_notify_queue_pages
• 29: max_parallel_maintenance_workers
• 30: max_parallel_workers
• 31: max_parallel_workers_per_gather
• 32: max_prepared_transactions
• 33: max_stack_depth
• 34: max_worker_processes
• 35: min_dynamic_shared_memory
• 36: multixact_member_buffers
• 37: multixact_offset_buffers
• 38: notify_buffers
• 39: old_snapshot_threshold
• 40: parallel_leader_participation
• 41: replacement_sort_tuples
• 42: serializable_buffers
• 43: shared_buffers
• 44: shared_memory_type
• 45: subtransaction_buffers
• 46: temp_buffers
• 47: temp_file_limit
• 48: timing_clock_source
• 49: transaction_buffers
• 50: vacuum_buffer_usage_limit
• 51: work_mem

1 - autovacuum_work_mem

Identity

Lifecycle

Default history

How it works

autovacuum_work_mem applies separately to each autovacuum worker process. The default sentinel -1 means to use maintenance_work_mem rather than negative memory.

The setting affects autovacuum workers only; it does not change manually issued VACUUM. It is a SIGHUP-context parameter, so it is configured at server level rather than as a per-session tuning knob.

Because multiple workers can run concurrently, the aggregate potential allocation is the per-worker value multiplied by active autovacuum workers. Memory is only one part of vacuum behavior; I/O throttling, worker count, thresholds, and table activity also matter.

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 literal negative kilobyte value instead of an inheritance sentinel.
• Assuming the setting controls manual VACUUM.
• Budgeting one worker while several autovacuum workers can run at once.
• Increasing memory to address a vacuum problem actually caused by I/O throttling, thresholds, locks, or insufficient worker capacity.

Related parameters

maintenance_work_mem · autovacuum_max_workers · autovacuum_worker_slots · vacuum_buffer_usage_limit · autovacuum_vacuum_cost_delay

References

• PostgreSQL 19 Beta 3 — autovacuum_work_mem
• PostgreSQL 18: The Autovacuum Daemon
• Pigsty: Parameter Templates
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - backend_flush_after

Identity

Lifecycle

Default history

How it works

After one backend has written more than backend_flush_after bytes, PostgreSQL asks the operating system to begin writing those dirty page-cache pages toward storage. Zero disables these writeback hints.

This is not fsync and does not make a transaction durable earlier. Its aim is to limit large dirty-page bursts and later stalls; support and effect depend on the operating system.

The threshold applies independently to each backend, so concurrent bulk writers can each generate writeback. It complements bgwriter_flush_after and checkpoint_flush_after, which cover different writer processes. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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

• Changing backend_flush_after without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

bgwriter_flush_after · checkpoint_flush_after · bgwriter_delay · shared_buffers · track_io_timing

References

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

3 - bgwriter_delay

Identity

Lifecycle

Default history

How it works

The background writer performs a round, writes selected dirty shared buffers, then sleeps for bgwriter_delay. When no dirty buffers are found it can enter a longer sleep regardless of this value.

A shorter interval reacts sooner to buffer demand but wakes the process more often. Effective timer granularity can be about 10 ms on some systems, so smaller or non-multiple values may round up in practice.

The number of pages considered per round is derived from recent buffer allocation demand, bgwriter_lru_multiplier, and bgwriter_lru_maxpages; checkpoints are handled separately. Its SIGHUP context allows configuration reload without a server restart.

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

• Changing bgwriter_delay without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

bgwriter_lru_maxpages · bgwriter_lru_multiplier · bgwriter_flush_after · shared_buffers · checkpoint_completion_target

References

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

4 - bgwriter_flush_after

Identity

Lifecycle

Default history

How it works

After the background writer has written more than bgwriter_flush_after bytes, PostgreSQL asks the operating system to begin writing those page-cache pages toward storage. Zero disables the request.

The request is writeback smoothing, not a durability fsync. It can reduce large kernel flush stalls, but can also hurt workloads that benefit from retaining dirty data in the OS cache, and it has no effect on unsupported platforms.

The measured Docker/Linux boot value represents Linux behavior; PostgreSQL documents a platform-dependent default of 512kB on Linux and zero elsewhere. Backend and checkpointer writeback have separate thresholds. Its SIGHUP context allows configuration reload without a server restart.

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

• Changing bgwriter_flush_after without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

backend_flush_after · checkpoint_flush_after · bgwriter_delay · bgwriter_lru_maxpages · shared_buffers

References

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

5 - bgwriter_lru_maxpages

Identity

Lifecycle

Default history

How it works

bgwriter_lru_maxpages caps how many LRU-selected dirty buffers the background writer writes in one round. Zero disables this background-writing activity but does not disable checkpoints.

The writer tries to create enough clean reusable buffers for predicted demand, but this cap bounds each round. If it is reached repeatedly, foreground backends may still have to write buffers themselves.

The prediction comes from recent allocations multiplied by bgwriter_lru_multiplier, and rounds are separated by bgwriter_delay. Raising the cap can smooth latency at the cost of extra write amplification. Its SIGHUP context allows configuration reload without a server restart.

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

• Changing bgwriter_lru_maxpages without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

bgwriter_lru_multiplier · bgwriter_delay · bgwriter_flush_after · shared_buffers · checkpoint_completion_target

References

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

6 - bgwriter_lru_multiplier

Identity

Lifecycle

Default history

How it works

The background writer averages recent buffer allocations and multiplies that demand by bgwriter_lru_multiplier to choose a target number of clean reusable buffers. A value above 1 adds cushion for bursts.

This is a forecast multiplier, not a direct number of pages. Actual writes remain capped by bgwriter_lru_maxpages and occur once per bgwriter_delay round.

More cushion can reduce foreground backend writes and latency spikes, but pages dirtied repeatedly between checkpoints may be written more times, increasing total I/O. Its SIGHUP context allows configuration reload without a server restart.

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

• Changing bgwriter_lru_multiplier without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

bgwriter_lru_maxpages · bgwriter_delay · bgwriter_flush_after · shared_buffers · checkpoint_completion_target

References

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

7 - commit_timestamp_buffers

Identity

Lifecycle

Default history

How it works

commit_timestamp_buffers allocates a dedicated startup-time shared buffer pool for pages in pg_commit_ts, the SLRU area used when commit timestamp tracking is enabled.

A configured zero is an automatic sizing request, not zero memory: PostgreSQL derives shared_buffers/512, clamps it to at least 16 and at most 1024 blocks, and allocates the result at server start.

The cache can reduce pg_commit_ts reads but does not enable commit timestamp collection; track_commit_timestamp is the separate functional switch. Increasing it consumes real shared memory. Its postmaster context fixes the value at server start; changing it requires a restart.

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

• Changing commit_timestamp_buffers without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

track_commit_timestamp · shared_buffers · transaction_buffers · subtransaction_buffers

References

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

8 - dynamic_shared_memory_type

Identity

Lifecycle

Default history

How it works

dynamic_shared_memory_type selects how PostgreSQL creates dynamic shared memory segments used by parallel query and extensions: POSIX, System V, Windows, or file-backed mmap where supported.

The available enum values and selected boot default are platform dependent. The Docker/Linux catalog reports posix; that is not a portable promise for Windows or systems lacking POSIX shared memory.

The mmap implementation stores mapped files under pg_dynshmem and is generally discouraged because dirty pages may be written repeatedly. min_dynamic_shared_memory can preallocate part of parallel-query memory in the main shared region. Its postmaster context fixes the value at server start; changing it requires a restart.

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 Linux-Docker posix boot value as portable to platforms without POSIX shared memory.
• Using file-backed mmap on ordinary storage and creating repeated dirty-page writeback.
• Selecting sysv without checking System V segment limits.
• Confusing dynamic segments with the main region selected by shared_memory_type.
• Changing the startup setting without testing parallel queries and extensions that allocate DSM.

Related parameters

shared_memory_type · min_dynamic_shared_memory · max_parallel_workers · max_worker_processes · huge_pages

References

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

9 - effective_io_concurrency

Identity

Lifecycle

Default history

How it works

effective_io_concurrency tells one session how much storage concurrency it should try to exploit; it is not a cluster-wide queue cap. A tablespace option of the same name can override the session setting for data on that storage.

In PG10–17 it mainly controls prefetch distance for supported paths and platforms. The measured Linux-Docker boot value is 1, but unsupported platforms without effective posix_fadvise used 0 as the default; that platform condition must accompany any historical default claim.

PostgreSQL 18 integrates the setting with core asynchronous I/O, uses a boot default of 16, and allows 0 to disable asynchronous requests governed by this target. io_max_concurrency remains the separate per-process execution ceiling, and combine limits control bytes per request.

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 this per-session target as a cluster-wide cap; many sessions can multiply outstanding I/O.
• Calling 1 the unconditional PG10–17 upstream default even though unsupported platforms defaulted to 0.
• Applying PG18 AIO behavior to older releases that used the setting chiefly for prefetch advice.
• Using one global value for mixed-storage tablespaces instead of considering tablespace overrides.
• Raising the target until device queueing increases latency for every session.

Related parameters

maintenance_io_concurrency · io_method · io_max_concurrency · io_combine_limit · random_page_cost · effective_cache_size

References

• PostgreSQL 19 Beta 3 — effective_io_concurrency
• PostgreSQL 18 release notes: asynchronous I/O and new default
• PostgreSQL 19 release notes
• Machine-readable GUC export

10 - file_copy_method

Identity

Lifecycle

Default history

How it works

file_copy_method chooses COPY or CLONE for CREATE DATABASE … STRATEGY=FILE_COPY and ALTER DATABASE … SET TABLESPACE. It does not change SQL COPY or general file reads.

CLONE uses copy_file_range() on Linux/FreeBSD or copyfile on macOS, allowing supporting file systems to share blocks or offload the operation. Availability and the actual optimization depend on the operating system and file system; selecting CLONE does not prove that blocks were shared.

Copy-on-write can make the initial operation fast, but later writes allocate private blocks and snapshots still share failure domains. Backup, quota, and free-space accounting must understand the file system semantics. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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 CLONE guarantees copy-on-write block sharing; the kernel and file system decide the actual optimization.
• Expecting the parameter to affect SQL COPY or ordinary relation reads.
• Ignoring later private-block allocation and free-space pressure after a fast clone.
• Using CLONE before backup, quota, and filesystem tooling understand shared extents.

Related parameters

file_extend_method · data_directory · temp_tablespaces · shared_buffers

References

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

11 - file_extend_method

Identity

Lifecycle

Default history

How it works

file_extend_method chooses how PostgreSQL grows relation files during bulk extension: posix_fallocate when available or explicit zero writes. Extensions of eight blocks or fewer still use zero writes.

The first supported method is platform dependent. posix_fallocate reserves space without writing every block, but unsupported file systems silently fall back; on current BTRFS it can disable compression for the file.

This affects allocation behavior and bulk-write latency, not WAL durability. Storage reservations, sparse-file behavior, compression, and copy-on-write semantics vary by file system. Its SIGHUP context allows configuration reload without a server restart.

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

• Changing file_extend_method without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

file_copy_method · backend_flush_after · checkpoint_flush_after · wal_sync_method

References

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

12 - hash_mem_multiplier

Identity

Lifecycle

Default history

How it works

The memory ceiling for a hash table is work_mem multiplied by hash_mem_multiplier. It applies to hash joins, hash aggregation, memoize nodes, and other hash-based executor work, but does not enlarge the limit for sort operations.

The parameter first appears in the PG9.0–19 Beta 3 inventory in PostgreSQL 13. Its boot default is 1.0 in PostgreSQL 13–14 and 2.0 from PostgreSQL 15 onward.

A query can contain several hash operations, and parallel workers can execute their own operations, so the product is still an operation-level limit rather than a whole-query memory cap.

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 the value as an absolute memory size rather than a multiplier of work_mem.
• Forgetting that it has no effect before PostgreSQL 13 and that the upstream default changed in PostgreSQL 15.
• Expecting it to help sorts, which remain governed by work_mem.
• Multiplying only once per query despite multiple hash nodes or parallel workers.

Related parameters

work_mem · temp_file_limit · enable_hashjoin · enable_hashagg · max_parallel_workers_per_gather

References

• PostgreSQL 19 Beta 3 — hash_mem_multiplier
• Pigsty: Parameter Templates
• PostgreSQL 19 release notes
• Machine-readable GUC export

13 - huge_page_size

Identity

Lifecycle

Default history

How it works

huge_page_size selects the explicit huge-page size requested for PostgreSQL’s main shared-memory area when huge_pages is used. Zero means the operating system’s default huge-page size.

This is a startup allocation choice, not an amount of memory. Supported nonzero sizes are architecture and kernel dependent, and PostgreSQL currently supports nondefault selection only on Linux.

The requested page size must match provisioned huge-page pools and the shared-memory allocation. It affects the main shared area, not ordinary backend allocations such as work_mem. Its postmaster context fixes the value at server start; changing it requires a restart.

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 0 as zero-byte huge pages rather than ‘use the system default huge-page size’.
• Selecting a nonzero size on a non-Linux platform, where nondefault sizes are not supported.
• Requesting a page size whose kernel pool has not been provisioned and causing startup failure when huge_pages=on.
• Confusing explicit huge pages for the main shared-memory area with Transparent Huge Pages or per-backend memory.

Related parameters

huge_pages · huge_pages_status · shared_buffers · shared_memory_type · min_dynamic_shared_memory

References

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

14 - huge_pages

Identity

Lifecycle

Default history

How it works

huge_pages affects the main shared-memory area and is evaluated only at server start. try requests huge pages and falls back to normal pages, on makes failure fatal, and off skips the request.

Explicit huge pages can reduce page-table size and CPU time spent on memory management, especially with a large contiguous shared-memory allocation. On Linux, PostgreSQL requires shared_memory_type=mmap and enough pre-provisioned huge pages; huge_pages_status reports the actual outcome.

Explicit HugeTLB pages are not the same as Linux Transparent Huge Pages. PostgreSQL documentation currently discourages THP for some Linux versions even while describing explicit huge pages as potentially beneficial.

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 explicit huge pages with Transparent Huge Pages.
• Setting on before provisioning enough pages, causing PostgreSQL startup to fail.
• Assuming the setting covers work_mem or other ordinary per-process allocations; it targets the main shared-memory area.
• Checking configuration but not the runtime huge_pages_status result.

Related parameters

huge_page_size · huge_pages_status · shared_buffers · shared_memory_type · min_dynamic_shared_memory

References

• PostgreSQL 19 Beta 3 — huge_pages
• PostgreSQL 18: Linux Huge Pages
• Pigsty: Node huge-page parameters
• Pigsty: Parameter Templates
• PostgreSQL 19 release notes
• Machine-readable GUC export

15 - io_combine_limit

Identity

Lifecycle

Default history

How it works

io_combine_limit limits the byte size of one I/O request formed by combining adjacent eligible operations. It controls bytes per request, not the number of requests that may execute concurrently.

In PostgreSQL 17 it is a standalone user-settable combine-size limit with a measured Linux-Docker boot value of 128kB; io_max_combine_limit does not exist in that release. In PostgreSQL 18, the effective size is the lower of io_combine_limit and the new server-start io_max_combine_limit.

Actual requests can be smaller when adjacent work is unavailable, and operating-system plus BLCKSZ constraints bound the feasible maximum. Its user context permits session- or transaction-local changes; changing it does not alter io_max_concurrency or worker count.

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

• Applying the PG18 io_max_combine_limit clamp to PostgreSQL 17, where that GUC does not exist.
• Treating a byte-size limit as I/O concurrency or queue depth.
• Raising io_combine_limit above the PG18 server clamp and expecting larger requests.
• Assuming every eligible operation reaches the configured size even when adjacent I/O is unavailable.

Related parameters

io_max_combine_limit · io_max_concurrency · io_method · effective_io_concurrency · maintenance_io_concurrency

References

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

16 - io_max_combine_limit

Identity

Lifecycle

Default history

How it works

io_max_combine_limit is the server-start ceiling that silently clamps the user-settable io_combine_limit. It protects the I/O subsystem from request sizes beyond the configured server policy.

This controls bytes per combined operation, not queue depth. The feasible maximum depends on operating system and BLCKSZ, typically 1MB on Unix and 128kB on Windows.

Raising io_combine_limit above this value has no effect until this startup parameter is also raised. Combined requests can still be smaller when adjacent work is unavailable. Its postmaster context fixes the value at server start; changing it requires a restart.

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 server byte-size clamp as an I/O concurrency limit.
• Raising io_max_combine_limit while io_combine_limit remains lower and expecting a change.
• Expecting larger combined requests when adjacent eligible operations do not exist.
• Ignoring operating-system and BLCKSZ limits, especially the smaller typical Windows maximum.
• Forgetting that a change requires a server restart.

Related parameters

io_combine_limit · io_max_concurrency · io_method · shared_buffers

References

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

17 - io_max_concurrency

Identity

Lifecycle

Default history

How it works

io_max_concurrency is a PostgreSQL 18 server-start ceiling on the number of I/O operations that one process may execute simultaneously. It is per process, not a reservation and not a cluster-wide cap.

The default -1 asks PostgreSQL to derive a value from shared_buffers and configured process maxima, capped at 64. Because many backends and workers can each reach their own ceiling, possible cluster-wide outstanding I/O can be much larger.

effective_io_concurrency and maintenance_io_concurrency are workload targets below this ceiling; io_method chooses the execution mechanism, and combine limits control bytes per request. Changing io_max_concurrency requires a restart.

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 per-process ceiling as a cluster-wide I/O limit.
• Reading -1 as unlimited rather than automatic sizing capped at 64.
• Calling the ceiling reserved capacity; it permits concurrency but does not preallocate I/O slots.
• Confusing operation count with io_combine_limit’s bytes per request.
• Changing the value without a restart or without multiplying exposure across processes.

Related parameters

io_method · io_workers · effective_io_concurrency · maintenance_io_concurrency · io_combine_limit · max_connections

References

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

18 - io_max_workers

Identity

Lifecycle

Default history

How it works

PostgreSQL describes io_max_workers as follows: “Maximum number of I/O worker processes, for io_method=worker.” 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.

These controls govern the elastic background-worker pool used only when io_method is worker. io_min_workers keeps warm capacity, io_max_workers caps the pool, io_worker_launch_interval damps short bursts, and io_worker_idle_timeout lets unused workers retire; they do not raise a backend’s separate io_max_concurrency ceiling.

Read it together with io_min_workers, io_worker_idle_timeout, io_worker_launch_interval, io_method. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for io_max_workers 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.

Related parameters

io_min_workers · io_worker_idle_timeout · io_worker_launch_interval · io_method · io_max_concurrency · io_combine_limit

References

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

19 - io_method

Identity

Lifecycle

Default history

How it works

worker sends eligible I/O through dedicated I/O worker processes; io_uring uses Linux io_uring and requires a build with liburing support; sync performs asynchronous-eligible operations synchronously. The upstream default is worker.

The PG18 AIO subsystem allows backends to queue multiple reads and can improve sequential scans, bitmap heap scans, vacuum, and other supported operations. It does not make every PostgreSQL I/O path asynchronous.

io_workers matters only when worker is selected. io_max_concurrency and the I/O combine limits control different dimensions of queue depth and request size, so method selection should be evaluated with them and with the storage stack.

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

• The parameter does not exist before PostgreSQL 18.
• Changing it requires a server restart.
• io_uring requires operating-system and build support; the enum value alone does not provide that support.
• io_workers has no effect unless io_method=worker.
• AIO benefits only eligible paths and cannot compensate for an overloaded or poorly configured storage layer.

Related parameters

io_workers · io_max_concurrency · io_combine_limit · io_max_combine_limit · effective_io_concurrency · maintenance_io_concurrency

References

• PostgreSQL 19 Beta 3 — io_method
• PostgreSQL 18 release notes: asynchronous I/O subsystem
• PostgreSQL 19 release notes
• Machine-readable GUC export

20 - io_min_workers

Identity

Lifecycle

Default history

How it works

PostgreSQL describes io_min_workers as follows: “Minimum number of I/O worker processes, for io_method=worker.” 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.

These controls govern the elastic background-worker pool used only when io_method is worker. io_min_workers keeps warm capacity, io_max_workers caps the pool, io_worker_launch_interval damps short bursts, and io_worker_idle_timeout lets unused workers retire; they do not raise a backend’s separate io_max_concurrency ceiling.

Read it together with io_max_workers, io_worker_idle_timeout, io_worker_launch_interval, io_method. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for io_min_workers 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.

Related parameters

io_max_workers · io_worker_idle_timeout · io_worker_launch_interval · io_method · io_max_concurrency · io_combine_limit

References

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

21 - io_worker_idle_timeout

Identity

Lifecycle

Default history

How it works

PostgreSQL describes io_worker_idle_timeout as follows: “Maximum time before idle I/O worker processes time out, for io_method=worker.” 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.

These controls govern the elastic background-worker pool used only when io_method is worker. io_min_workers keeps warm capacity, io_max_workers caps the pool, io_worker_launch_interval damps short bursts, and io_worker_idle_timeout lets unused workers retire; they do not raise a backend’s separate io_max_concurrency ceiling.

Read it together with io_min_workers, io_max_workers, io_worker_launch_interval, io_method. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for io_worker_idle_timeout 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.

Related parameters

io_min_workers · io_max_workers · io_worker_launch_interval · io_method · io_max_concurrency · io_combine_limit

References

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

22 - io_worker_launch_interval

Identity

Lifecycle

Default history

How it works

PostgreSQL describes io_worker_launch_interval as follows: “Minimum time before launching a new I/O worker process, for io_method=worker.” 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.

These controls govern the elastic background-worker pool used only when io_method is worker. io_min_workers keeps warm capacity, io_max_workers caps the pool, io_worker_launch_interval damps short bursts, and io_worker_idle_timeout lets unused workers retire; they do not raise a backend’s separate io_max_concurrency ceiling.

Read it together with io_min_workers, io_max_workers, io_worker_idle_timeout, io_method. 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 PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for io_worker_launch_interval 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.

Related parameters

io_min_workers · io_max_workers · io_worker_idle_timeout · io_method · io_max_concurrency · io_combine_limit

References

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

23 - io_workers

Identity

Lifecycle

Default history

How it works

io_workers sets the number of dedicated I/O worker processes used by PostgreSQL 18 when io_method=worker. It has no effect for io_uring or sync.

I/O workers execute asynchronous requests on behalf of database processes; this is an execution pool, distinct from parallel query workers and background worker slots.

Changing the count is reloadable, but useful capacity still depends on io_max_concurrency, workload queue depth, storage latency, and CPU. More workers do not guarantee more device throughput. Its SIGHUP context allows configuration reload without a server restart.

Tuning advice

Pigsty

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

Common pitfalls

• Changing io_workers while io_method is io_uring or sync, where it has no effect.
• Treating worker-process count as bytes per request or as the per-process I/O ceiling.
• Adding workers when the storage device, not the worker pool, is already saturated.
• Forgetting that the reloadable pool still consumes process slots, CPU, and scheduling capacity.

Related parameters

io_method · io_max_concurrency · effective_io_concurrency · maintenance_io_concurrency · max_worker_processes

References

• PostgreSQL 18 — io_workers
• Machine-readable GUC export

24 - logical_decoding_work_mem

Identity

Lifecycle

Default history

How it works

logical_decoding_work_mem is the real memory threshold for one logical decoding stream before decoded changes are written to local temporary files. It is independent of ordinary query work_mem.

Each replication connection uses one such buffer, and concurrency is bounded by replication sender capacity rather than client sessions. Large in-progress transactions can spill and later be reread.

Raising the threshold can reduce serialization I/O for logical replication, but the cluster memory budget must multiply it by concurrent decoding streams and include output-plugin memory outside this accounting. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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

• Changing logical_decoding_work_mem without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

work_mem · max_wal_senders · max_replication_slots · debug_logical_replication_streaming · temp_file_limit

References

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

25 - maintenance_io_concurrency

Identity

Lifecycle

Default history

How it works

maintenance_io_concurrency is the per-maintenance-operation target for storage concurrency used by work performed on behalf of many clients. A tablespace option of the same name can override it for that storage; it is neither a cluster-wide device cap nor a memory allocation.

In PG13–17 it chiefly controls maintenance prefetch on supported systems. The measured Linux-Docker boot value is 10, while unsupported platforms without effective prefetch-advice support defaulted to 0; those releases do not have the PG18 core-AIO execution model.

PostgreSQL 18 integrates the target with core AIO and uses a boot default of 16. io_max_concurrency separately clamps simultaneous execution by one process, io_method chooses the execution mechanism, and combine limits control bytes per request. Its user context permits scoped runtime changes.

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

• Calling 10 the unconditional PG13–17 default when unsupported platforms used 0.
• Back-projecting PG18 core-AIO semantics into PG13–17 prefetch behavior.
• Treating the per-operation target as a cluster or device-wide cap.
• Confusing concurrency with io_combine_limit’s bytes-per-request dimension.
• Using one value across tablespaces with materially different storage.

Related parameters

effective_io_concurrency · io_method · io_max_concurrency · io_combine_limit · vacuum_buffer_usage_limit

References

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

26 - maintenance_work_mem

Identity

Lifecycle

Default history

How it works

maintenance_work_mem applies to maintenance operations including VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY. Because a session normally runs only one such operation at a time, it can usually be set higher than work_mem.

For parallel utility commands, PostgreSQL treats maintenance_work_mem as a limit for the entire utility command rather than granting the full amount to every parallel maintenance worker. CPU and I/O consumption can still rise with parallelism.

Autovacuum is a separate concurrency concern: when autovacuum_work_mem is -1, each autovacuum worker inherits maintenance_work_mem, so several workers can make the aggregate budget much larger than the single-operation 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 the value is harmless because maintenance is infrequent while leaving autovacuum_work_mem at -1.
• Multiplying the limit by parallel maintenance workers; PostgreSQL applies it to the utility command as a whole.
• Using a permanently large cluster-wide value for a one-off restore instead of a scoped SET.
• Expecting more memory alone to solve maintenance dominated by locks or storage I/O.

Related parameters

autovacuum_work_mem · autovacuum_max_workers · max_parallel_maintenance_workers · vacuum_buffer_usage_limit · work_mem

References

• PostgreSQL 19 Beta 3 — maintenance_work_mem
• PostgreSQL 18: Routine Vacuuming
• Pigsty: Parameter Optimization Policy
• PostgreSQL 19 release notes
• Machine-readable GUC export

27 - max_files_per_process

Identity

Lifecycle

Default history

How it works

max_files_per_process is PostgreSQL’s startup-time expectation for how many files one server subprocess may keep open, excluding files inherited already open from the postmaster.

It does not raise the kernel’s file-descriptor limit. PostgreSQL uses it in resource management, and on kernels that overcommit descriptors across processes a lower value can prevent system-wide exhaustion.

The relevant capacity is per process multiplied across backends and workers. ‘Too many open files’ can also require fixing OS service limits, connection counts, partition fan-out, or extension behavior. Its postmaster context fixes the value at server start; changing it requires a restart.

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 the GUC to raise ulimit or the service manager’s nofile limit.
• Sizing only per process and ignoring the aggregate across connections and workers.
• Raising the value to hide a descriptor leak or excessive partition/index fan-out.
• Forgetting that files inherited already open from the postmaster are excluded from this count.

Related parameters

max_connections · max_worker_processes · max_wal_senders · shared_preload_libraries

References

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

28 - max_notify_queue_pages

Identity

Lifecycle

Default history

How it works

max_notify_queue_pages caps the number of database pages that the disk-backed LISTEN/NOTIFY queue may allocate. At the usual 8kB BLCKSZ, the PG18 default permits up to 8GB.

Notifications remain queued until all listening sessions have consumed or no longer need them. A listener that stays inside a long transaction can prevent cleanup and let queue usage grow.

This is disk capacity, not notify_buffers memory and not a limit on one payload. When the queue is full, transactions attempting NOTIFY can fail at commit. Its postmaster context fixes the value at server start; changing it requires a restart.

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

• Increasing queue capacity instead of fixing a listener that stays inside a long transaction.
• Confusing max_notify_queue_pages disk capacity with notify_buffers shared-memory cache.
• Forgetting that, with 8kB pages, the default 1048576 pages permits up to about 8GB.
• Assuming a larger queue changes an individual NOTIFY payload limit or delivery semantics.

Related parameters

notify_buffers · track_activities · max_connections · shared_buffers

References

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

29 - max_parallel_maintenance_workers

Identity

Lifecycle

Default history

How it works

max_parallel_maintenance_workers caps workers requested by one supported maintenance command, such as parallel CREATE INDEX or VACUUM. The leader is additional and may also perform work.

The cap does not reserve workers or guarantee they will be available. Requests compete within max_parallel_workers and max_worker_processes, and operation-specific rules can choose fewer.

Parallel maintenance can multiply CPU and I/O pressure; CREATE INDEX memory follows maintenance-specific accounting rather than simply granting maintenance_work_mem independently to every worker. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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 max_parallel_maintenance_workers as reserved capacity rather than an upper bound shared with other work.
• Ignoring that parallel plans multiply CPU, I/O, and work_mem-limited nodes.
• Benchmarking one query without concurrent worker contention.
• Assuming planned workers will always be launched at execution time.

Related parameters

max_parallel_workers · max_worker_processes · maintenance_work_mem · maintenance_io_concurrency · max_parallel_workers_per_gather

References

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

30 - max_parallel_workers

Identity

Lifecycle

Default history

How it works

max_parallel_workers caps the cluster-wide number of workers simultaneously active for parallel query and maintenance. It is a pool ceiling beneath max_worker_processes.

Per-operation parameters request workers from this pool, but no slots are reserved. A plan can start with fewer workers than planned, and concurrent jobs can starve each other.

Increasing it expands potential CPU, memory, and I/O concurrency; it does not itself make plans parallel. Planner thresholds, safety checks, and max_parallel_workers_per_gather still govern query choices. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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 max_parallel_workers as reserved capacity rather than an upper bound shared with other work.
• Ignoring that parallel plans multiply CPU, I/O, and work_mem-limited nodes.
• Benchmarking one query without concurrent worker contention.
• Assuming planned workers will always be launched at execution time.

Related parameters

max_worker_processes · max_parallel_workers_per_gather · max_parallel_maintenance_workers · parallel_setup_cost · parallel_leader_participation

References

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

31 - max_parallel_workers_per_gather

Identity

Lifecycle

Default history

How it works

max_parallel_workers_per_gather limits how many workers one Gather or Gather Merge node may request. Zero prevents parallel query execution through these nodes without disabling other background workers.

Workers are not reserved and can be unavailable at execution time because max_parallel_workers and max_worker_processes are shared pools. The leader process is not included in this numeric limit.

Each parallel plan can multiply work_mem-limited nodes, CPU demand, and I/O. The planner weighs parallel_setup_cost and parallel_tuple_cost before deciding whether to request workers. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the 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 max_parallel_workers_per_gather as reserved capacity rather than an upper bound shared with other work.
• Ignoring that parallel plans multiply CPU, I/O, and work_mem-limited nodes.
• Benchmarking one query without concurrent worker contention.
• Assuming planned workers will always be launched at execution time.

Related parameters

max_parallel_workers · max_worker_processes · parallel_setup_cost · parallel_tuple_cost · parallel_leader_participation · work_mem

References

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

32 - max_prepared_transactions

Identity

Lifecycle

Default history

How it works

max_prepared_transactions reserves capacity for two-phase transactions left in the prepared state by PREPARE TRANSACTION. Zero disables creating prepared transactions.

Prepared transactions retain locks and transaction state across client disconnects and crashes until COMMIT PREPARED or ROLLBACK PREPARED. Capacity requires shared memory and durable state.

A standby must configure at least the primary’s value or read queries can be refused. This is unrelated to SQL prepared statements and should remain zero unless a two-phase commit coordinator is operationally managed. Its postmaster context fixes the value at server start; changing it requires a restart.

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

• Changing max_prepared_transactions without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

max_connections · max_locks_per_transaction · wal_level · max_wal_senders

References

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

33 - max_stack_depth

Identity

Lifecycle

Default history

How it works

max_stack_depth is a guard used by selected recursive execution paths. It neither allocates a process stack nor changes the operating-system stack limit; the kernel limit remains authoritative.

The catalog’s raw boot_val is 100kB in every measured PG9.0–19 Beta 3 image, but the same fresh containers report setting=2048kB, matching the documented 2MB default after configuration/initdb. The 100kB boot fallback must not be presented as the ordinary effective setting.

A safe explicit value is the kernel stack limit, such as ulimit -s, minus roughly 1MB because not every C call site checks depth. Setting it above the real limit can let runaway recursion crash a backend. Its superuser context allows an authorized runtime change without a restart.

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 boot_val=100kB with the measured and documented effective setting of 2048kB.
• Treating max_stack_depth as allocated memory or a way to reduce resident memory.
• Setting it above the kernel stack limit and allowing recursive code to crash a backend.
• Copying a value across hosts without checking the service manager and ulimit stack settings.

Related parameters

max_worker_processes · shared_buffers · work_mem · max_connections

References

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

34 - max_worker_processes

Identity

Lifecycle

Default history

How it works

max_worker_processes is the startup-time ceiling for concurrent background worker processes, including parallel workers and extension-managed workers. It is broader than max_parallel_workers.

The setting allocates shared control capacity but does not launch workers. Replication, extensions, logical apply, and parallel execution can all depend on slots beneath this ceiling.

A standby should normally configure the same or a higher value than its primary because worker requirements can be replayed or promoted. Increasing it without a CPU and memory budget only creates possible concurrency. Its postmaster context fixes the value at server start; changing it requires a restart.

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_worker_processes as reserved capacity rather than an upper bound shared with other work.
• Ignoring that parallel plans multiply CPU, I/O, and work_mem-limited nodes.
• Benchmarking one query without concurrent worker contention.
• Assuming planned workers will always be launched at execution time.

Related parameters

max_parallel_workers · max_parallel_workers_per_gather · max_parallel_maintenance_workers · max_logical_replication_workers · max_wal_senders

References

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

35 - min_dynamic_shared_memory

Identity

Lifecycle

Default history

How it works

min_dynamic_shared_memory preallocates real memory at server start for parallel-query dynamic shared memory. It is a reserved pool, not a maximum and not an estimate of cache size.

When the pool is insufficient, parallel queries can still allocate temporary dynamic shared memory through dynamic_shared_memory_type, with additional operating-system allocation overhead.

Startup allocation joins the main shared-memory region and can benefit from huge pages where supported. Reserving too much consumes memory even when parallel work is absent. Its postmaster context fixes the value at server start; changing it requires a restart.

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 min_dynamic_shared_memory as a maximum instead of a real preallocated floor.
• Assuming parallel queries fail when the reserved pool is exhausted; PostgreSQL can allocate additional dynamic segments.
• Reserving memory that remains committed even when parallel work is absent.
• Ignoring dynamic_shared_memory_type, huge-page behavior, and the required restart.

Related parameters

dynamic_shared_memory_type · huge_pages · max_parallel_workers · max_parallel_workers_per_gather · shared_buffers

References

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

36 - multixact_member_buffers

Identity

Lifecycle

Default history

How it works

multixact_member_buffers allocates a dedicated shared buffer pool for pg_multixact/members, which caches MultiXact member entries. This is real startup shared memory, not a planner estimate.

The configured block count is allocated at server start. The unit is BLCKSZ blocks, normally 8kB.

A larger cache can reduce SLRU read/write churn for unusually heavy use of the underlying feature, but it permanently consumes shared memory and does not increase the feature’s logical capacity. Its postmaster context fixes the value at server start; changing it requires a restart.

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

• Changing multixact_member_buffers without applying its documented unit and configuration context.
• Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.
• Assuming a configured value guarantees operating-system or storage behavior.
• Failing to retest startup, failover, and workload latency after the change.

Related parameters

multixact_offset_buffers · shared_buffers · max_locks_per_transaction

References

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

37 - multixact_offset_buffers

Identity