Developer Options

• 1: allow_in_place_tablespaces
• 2: allow_system_table_mods
• 3: backtrace_functions
• 4: debug_discard_caches
• 5: debug_io_direct
• 6: debug_logical_replication_streaming
• 7: debug_parallel_query
• 8: force_parallel_mode
• 9: ignore_checksum_failure
• 10: ignore_invalid_pages
• 11: ignore_system_indexes
• 12: jit_debugging_support
• 13: jit_dump_bitcode
• 14: jit_expressions
• 15: jit_profiling_support
• 16: jit_tuple_deforming
• 17: post_auth_delay
• 18: pre_auth_delay
• 19: remove_temp_files_after_crash
• 20: send_abort_for_crash
• 21: send_abort_for_kill
• 22: trace_connection_negotiation
• 23: trace_notify
• 24: trace_recovery_messages
• 25: trace_sort
• 26: wal_consistency_checking
• 27: zero_damaged_pages

1 - allow_in_place_tablespaces

Identity

Lifecycle

Default history

How it works

allow_in_place_tablespaces lets a superuser create a tablespace with an empty location directly under pg_tblspc instead of using the normal external-location symbolic link. It exists to test primary and standby instances on one machine.

The directory layout violates assumptions made by backup and tablespace-management tools, which normally expect pg_tblspc entries to be links. It does not make colocated tablespaces independent storage.

The switch is consulted for the privileged CREATE TABLESPACE operation and is not a performance setting. Objects created this way can remain after the setting is turned off. Its superuser context permits an authorized session change 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

• Leaving allow_in_place_tablespaces enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

data_directory · wal_level · hot_standby · archive_mode

References

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

2 - allow_system_table_mods

Identity

Lifecycle

Default history

How it works

allow_system_table_mods removes protections against changing system-catalog structure and permits other normally forbidden catalog actions. Superuser status alone does not normally grant these operations.

Catalog definitions are coupled to PostgreSQL code, cache descriptors, bootstrap data, WAL, and upgrade assumptions. A superficially valid ALTER can create irreversible corruption or data loss.

The parameter exists for PostgreSQL development, bootstrap, and tightly controlled tooling. It does not provide a supported extension mechanism; extensions must use published catalog and hook interfaces. Its superuser context permits an authorized session change 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

• Leaving allow_system_table_mods enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

allow_in_place_tablespaces · ignore_system_indexes · zero_damaged_pages · wal_consistency_checking

References

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

3 - backtrace_functions

Identity

Lifecycle

Default history

How it works

backtrace_functions is a comma-separated list of internal C function names. If an error originates in a listed function, PostgreSQL appends a native backtrace to that error in the server log.

It matches C symbols, not SQL function names. Availability and symbol quality depend on platform, compiler, build flags, debug information, and whether functions were inlined.

The setting can target a narrow failure path without logging stacks for every error. Stack traces can expose implementation detail and increase log volume, so collection should be scoped and protected. Its superuser context permits an authorized session change 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

• Leaving backtrace_functions enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

log_error_verbosity · log_min_error_statement · compute_query_id · log_line_prefix

References

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

4 - debug_discard_caches

Identity

Lifecycle

Default history

How it works

debug_discard_caches invalidates system-catalog cache entries at the earliest opportunity; higher values recurse the behavior. Nonzero values make the server extremely slow to expose cache invalidation bugs.

It is supported only in builds compiled with DISCARD_CACHES_ENABLED, automatically associated with –enable-cassert. Production builds keep zero and reject attempts to change it.

The parameter tests correctness under pathological cache churn. It does not flush shared_buffers, the operating-system page cache, or ordinary query result caches. Its superuser context permits an authorized session change 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

• Leaving debug_discard_caches enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

ignore_system_indexes · shared_buffers · debug_parallel_query · allow_system_table_mods

References

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

5 - debug_io_direct

Identity

Lifecycle

Default history

How it works

debug_io_direct requests cache-bypassing file access for selected operations: data, wal, and wal_init. PostgreSQL maps this to O_DIRECT, F_NOCACHE, or FILE_FLAG_NO_BUFFERING according to platform.

The empty string disables direct I/O. Unsupported kernels or file systems can reject startup or fail operations, and alignment constraints differ across platforms.

PostgreSQL documentation explicitly describes current nondefault use as performance-reducing developer testing. It is distinct from the PG18 asynchronous-I/O method and should not be presented as a production cache policy. 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

• Leaving debug_io_direct enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

io_method · io_max_concurrency · wal_sync_method · shared_buffers · backend_flush_after

References

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

6 - debug_logical_replication_streaming

Identity

Lifecycle

Default history

How it works

debug_logical_replication_streaming forces large-transaction logical replication paths to stream or serialize immediately instead of waiting for normal buffering thresholds. buffered is the production behavior.

On a publisher, immediate streams each change when subscription streaming is enabled or serializes it otherwise, bypassing the logical_decoding_work_mem trigger. On a parallel subscriber, immediate forces file serialization instead of the normal shared-memory queue path.

The two sides therefore exercise different code paths. This is a regression and fault-reproduction control, not a latency or memory tuning shortcut. 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

• Leaving debug_logical_replication_streaming enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

logical_decoding_work_mem · max_logical_replication_workers · max_sync_workers_per_subscription · wal_level

References

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

7 - debug_parallel_query

Identity

Lifecycle

Default history

How it works

debug_parallel_query forces safe queries through parallel mode even when no performance benefit is expected. on adds a top-level Gather where safe; regress also hides testing-only output differences.

Parallel-safety restrictions still apply. The forced context can expose functions incorrectly marked parallel safe and can prohibit operations such as subtransactions even when no worker is ultimately available.

It replaced the earlier force_parallel_mode name in PG16. Its purpose is regression testing, not making production queries faster or overriding all parallel cost decisions. 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

• Leaving debug_parallel_query enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

force_parallel_mode · max_parallel_workers_per_gather · max_parallel_workers · parallel_setup_cost · parallel_leader_participation

References

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

8 - force_parallel_mode

Identity

Lifecycle

Default history

How it works

Through PG15, force_parallel_mode forced otherwise safe queries to run under a Gather so parallel-mode behavior could be tested even without an expected speedup. regress suppressed output differences for regression suites.

It did not make unsafe queries safe and could impose parallel-context restrictions even when no worker ran. The top-level Gather was diagnostic overhead rather than a plan hint.

PostgreSQL 16 removed this GUC and introduced debug_parallel_query for the testing role. Upgrade configurations must delete the old name and should not automatically enable the replacement in production. 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 PG15; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Leaving force_parallel_mode enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

debug_parallel_query · max_parallel_workers_per_gather · max_parallel_workers · parallel_setup_cost

References

• PostgreSQL 15 — force_parallel_mode
• Machine-readable GUC export

9 - ignore_checksum_failure

Identity

Lifecycle

Default history

How it works

With data checksums enabled, a page checksum mismatch normally aborts the current transaction. ignore_checksum_failure instead emits a warning and attempts to continue if the page header is still sane.

It does not repair the page or prove remaining tuples are valid. Continuing can crash, hide or propagate corruption, and a damaged header still stops access.

The only defensible use is controlled data salvage from an immutable copy after storage and backup recovery options are exhausted. Every read under this mode is suspect evidence, not restored integrity. Its superuser context permits an authorized session change 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

• Leaving ignore_checksum_failure enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

zero_damaged_pages · ignore_invalid_pages · data_checksums · wal_consistency_checking

References

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

10 - ignore_invalid_pages

Identity

Lifecycle

Default history

How it works

During recovery, WAL references to invalid pages normally cause PANIC and stop recovery. ignore_invalid_pages logs a warning and continues past those references.

The startup-only setting has effect only in recovery or standby mode. Skipping redo can lose data, propagate corruption, and leave structures internally inconsistent even if the server reaches a running state.

It is an emergency salvage mechanism after preserving evidence and exhausting correct restore paths. A server that starts under it must not be considered healthy or promoted into normal service. 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

• Leaving ignore_invalid_pages enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

ignore_checksum_failure · zero_damaged_pages · restore_command · wal_consistency_checking

References

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

11 - ignore_system_indexes

Identity

Lifecycle

Default history

How it works

ignore_system_indexes makes a newly started backend read system catalogs without using their indexes, while catalog modifications still update the indexes. It is intended to recover from damaged system indexes.

Because its backend context is fixed at session start, changing the setting inside an existing session is ineffective. Catalog scans can become very slow.

The mode does not repair an index; it only creates a path to inspect data and REINDEX the damaged system index. Leaving it enabled hides symptoms and imposes broad catalog overhead. Its backend context fixes the value during connection startup; an existing session cannot change it.

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

• Leaving ignore_system_indexes enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

allow_system_table_mods · ignore_checksum_failure · zero_damaged_pages · shared_buffers

References

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

12 - jit_debugging_support

Identity

Lifecycle

Default history

How it works

jit_debugging_support registers generated JIT functions with GDB when LLVM and the platform provide the required listener interfaces. It improves symbol visibility for debugger sessions.

The value is fixed at backend start and does not enable JIT itself. Queries still need jit, a provider, and cost thresholds to generate code.

Registration adds developer instrumentation and is useful only while debugging JIT internals or generated code. It is not a query-performance feature. Its superuser-backend context fixes the value during connection startup and restricts who may set it.

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

• Leaving jit_debugging_support enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

jit · jit_above_cost · jit_dump_bitcode · jit_profiling_support · jit_expressions

References

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

13 - jit_dump_bitcode

Identity

Lifecycle

Default history

How it works

jit_dump_bitcode writes generated LLVM IR/bitcode files inside data_directory for queries that actually run JIT. It exists to inspect and reproduce JIT compiler behavior.

It does not activate JIT and produces nothing when no query crosses the JIT gates. Generated artifacts can accumulate, consume disk, and contain details derived from executed expressions.

Only a tightly controlled debugging session should enable it; files require explicit collection and cleanup. Its superuser context permits an authorized session change 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

• Leaving jit_dump_bitcode enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

jit · jit_above_cost · jit_debugging_support · jit_profiling_support · data_directory

References

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

14 - jit_expressions

Identity

Lifecycle

Default history

How it works

jit_expressions controls whether expression evaluation is JIT compiled after the query has already crossed the top-level JIT cost gate. It does not activate JIT by itself.

Disabling it leaves expressions interpreted while other eligible JIT work can still occur. This isolates expression-code generation for testing correctness or compilation overhead.

The setting is a developer diagnostic rather than the normal way to tune JIT; jit_above_cost and the top-level jit switch govern production selection. 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

• Leaving jit_expressions enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

jit · jit_above_cost · jit_tuple_deforming · jit_inline_above_cost · jit_optimize_above_cost

References

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

15 - jit_profiling_support

Identity

Lifecycle

Default history

How it works

jit_profiling_support emits registration data so Linux perf can attribute samples to JIT-generated functions when LLVM support is available. Files are written under the server user’s ~/.debug/jit directory.

The value is fixed at backend start and does not enable JIT. It only affects queries that generate code after crossing normal JIT gates.

PostgreSQL does not clean the profiling files automatically. Long-lived or busy systems can accumulate sensitive artifacts and consume disk. Its superuser-backend context fixes the value during connection startup and restricts who may set it.

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

• Leaving jit_profiling_support enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

jit · jit_above_cost · jit_debugging_support · jit_dump_bitcode · data_directory

References

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

16 - jit_tuple_deforming

Identity

Lifecycle

Default history

How it works

jit_tuple_deforming controls JIT compilation of the code that extracts attributes from PostgreSQL heap tuples after a query crosses the main JIT gate.

Disabling it leaves tuple deforming interpreted while expression JIT and other compilation can remain active. This isolates a compiler path for correctness and overhead diagnosis.

It is not an independent performance switch for every scan. Tuple layout, selected columns, row count, jit_above_cost, and total compilation time determine any effect. 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

• Leaving jit_tuple_deforming enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

jit · jit_above_cost · jit_expressions · jit_inline_above_cost · cpu_tuple_cost

References

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

17 - post_auth_delay

Identity

Lifecycle

Default history

How it works

post_auth_delay pauses a newly created backend after authentication succeeds, giving a developer time to attach a debugger to that process. Zero disables the delay.

The backend-context value is fixed at session start. Authentication has completed, so the session and server resources are already allocated while it sleeps.

This intentionally increases connection latency and can consume backend slots under connection storms. It is not a throttling, security, or connection-pooling control. Its backend context fixes the value during connection startup; an existing session cannot change it.

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

• Leaving post_auth_delay enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

pre_auth_delay · authentication_timeout · max_connections · log_connections

References

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

18 - pre_auth_delay

Identity

Lifecycle

Default history

How it works

pre_auth_delay pauses a newly forked server process before authentication so a developer can attach a debugger to handshake and authentication code. Zero disables it.

The SIGHUP setting applies to future connection startups. While a process sleeps, the client is unauthenticated and a server process and connection slot can remain occupied.

It intentionally delays every affected connection and can amplify denial-of-service exposure. It is not a replacement for authentication_timeout or network rate limiting. 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

• Leaving pre_auth_delay enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

post_auth_delay · authentication_timeout · max_connections · trace_connection_negotiation

References

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

19 - remove_temp_files_after_crash

Identity

Lifecycle

Default history

How it works

After a backend crash, remove_temp_files_after_crash controls whether PostgreSQL removes temporary files left by the failed process. on is the normal cleanup behavior.

Turning it off preserves artifacts for forensic debugging but repeated failures can accumulate useless files and exhaust the temporary-file file systems.

The setting does not prevent a crash, recover query state, or retain ordinary temporary tables for reuse. Any forensic retention needs explicit space monitoring and later cleanup. 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

• Leaving remove_temp_files_after_crash enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

temp_file_limit · temp_tablespaces · log_temp_files · send_abort_for_crash

References

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

20 - send_abort_for_crash

Identity

Lifecycle

Default history

How it works

After one backend crashes, the postmaster normally asks remaining children to stop with SIGQUIT. send_abort_for_crash substitutes SIGABRT so those peer processes normally produce core dumps.

The dumps capture peer state around the incident, not just the original crashing process. Repeated crashes can therefore create many large core files.

PostgreSQL provides no automatic core-file cleanup. OS core limits, storage capacity, privacy, and a collection workflow must be configured before enabling it. 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

• Leaving send_abort_for_crash enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

send_abort_for_kill · remove_temp_files_after_crash · log_error_verbosity · data_directory

References

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

21 - send_abort_for_kill

Identity

Lifecycle

Default history

How it works

When a child does not exit after SIGQUIT, the postmaster normally escalates to SIGKILL after five seconds. send_abort_for_kill uses SIGABRT instead so the stuck child normally writes a core dump.

SIGABRT provides forensic state but can take time and disk space, potentially delaying crash recovery. It is not guaranteed to terminate as promptly as SIGKILL in every failure mode.

PostgreSQL does not clean generated cores. OS policy and monitoring must prevent repeated stuck processes from filling storage. 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

• Leaving send_abort_for_kill enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

send_abort_for_crash · remove_temp_files_after_crash · log_error_verbosity · data_directory

References

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

22 - trace_connection_negotiation

Identity

Lifecycle

Default history

How it works

trace_connection_negotiation logs details from the pre-authentication connection negotiation path, providing evidence for protocol, encryption, and handshake debugging before normal authentication logs are available.

It is a server-start setting, so enabling it affects subsequent connection handshakes cluster-wide until restart. It does not alter authentication rules or make negotiation succeed.

Handshake logs can be high-volume and reveal network or client capability details. Use a controlled reproduction and protect the resulting server logs. 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

• Leaving trace_connection_negotiation enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

log_connections · authentication_timeout · ssl · pre_auth_delay · log_error_verbosity

References

• PostgreSQL 19 release notes
• Machine-readable GUC export

23 - trace_notify

Identity

Lifecycle

Default history

How it works

trace_notify emits extensive internal debugging messages for LISTEN and NOTIFY. Output is visible only when client_min_messages or log_min_messages includes DEBUG1 or lower.

It traces implementation activity rather than providing a durable audit of notification payloads. The extra messages can be much larger than the application notification stream.

Use it to reproduce queue and delivery bugs in a controlled session. Queue capacity and cleanup are governed separately by max_notify_queue_pages and listener transaction behavior. 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

• Leaving trace_notify enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

max_notify_queue_pages · notify_buffers · client_min_messages · log_min_messages · track_activities

References

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

24 - trace_recovery_messages

Identity

Lifecycle

Default history

How it works

Through PG16, trace_recovery_messages remapped recovery DEBUG messages at or above a chosen severity to LOG, making normally hidden recovery internals visible during testing.

It changed message visibility, not recovery decisions, WAL replay order, or durability. Verbose recovery logging could be extremely large and timing-sensitive.

PostgreSQL 17 removed the parameter. Upgrade configurations must delete it; current recovery diagnosis should use supported logging, progress, and WAL inspection facilities. 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 PG16; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Leaving trace_recovery_messages enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

log_min_messages · restore_command · recovery_min_apply_delay · wal_consistency_checking

References

• PostgreSQL 16 — trace_recovery_messages
• Machine-readable GUC export

25 - trace_sort

Identity

Lifecycle

Default history

How it works

trace_sort emits internal resource-use messages for sort operations, including memory, run generation, merge passes, and timing details useful to PostgreSQL developers.

It is diagnostic logging, not the same as EXPLAIN’s Sort Method output or log_temp_files. Enabling it can produce many messages on sort-heavy workloads.

The switch does not alter work_mem, the sorting algorithm, or spill thresholds. It should be scoped to a reproduction and paired with log-level settings that actually capture the output. 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

• Leaving trace_sort enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

work_mem · log_temp_files · enable_sort · temp_file_limit · log_min_messages

References

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

26 - wal_consistency_checking

Identity

Lifecycle

Default history

How it works

wal_consistency_checking names WAL resource managers whose redo routines should be verified. For selected records, PostgreSQL includes full-page images and after replay compares the resulting buffers with those images.

Unexpected differences terminate recovery with a fatal error; known nondeterministic differences such as some hint bits are handled specially. all enables every supported resource manager.

The added full-page images can greatly increase WAL volume and replay work. This finds redo implementation bugs; it is not a general on-disk checksum, backup verification, or corruption repair tool. Its superuser context permits an authorized session change 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

• Leaving wal_consistency_checking enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

full_page_writes · wal_log_hints · ignore_invalid_pages · ignore_checksum_failure · wal_level

References

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

27 - zero_damaged_pages

Identity

Lifecycle

Default history

How it works

When PostgreSQL detects a damaged page header, zero_damaged_pages substitutes an all-zero page in memory, emits a warning, and continues. Every row formerly on that page is thereby lost to the salvage read.

The zero page is not forced to disk automatically, so continuing to use the relation can produce inconsistent behavior. The table or index must be rebuilt after salvage.

This is a last-resort data-extraction switch after backups and storage recovery are exhausted. It must be used on a preserved copy, scoped narrowly, and turned off immediately afterward. Its superuser context permits an authorized session change 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

• Leaving zero_damaged_pages enabled after the bounded diagnostic or recovery task.
• Running the experiment on the only copy of production data.
• Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
• Treating a server that merely starts or completes a query as proof that data and behavior are correct.

Related parameters

ignore_checksum_failure · ignore_invalid_pages · data_checksums · wal_consistency_checking

References

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