????
Your IP : 3.133.141.175
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>20.17. Developer Options</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="runtime-config-custom.html" title="20.16. Customized Options" /><link rel="next" href="runtime-config-short.html" title="20.18. Short Options" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">20.17. Developer Options</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="runtime-config-custom.html" title="20.16. Customized Options">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><th width="60%" align="center">Chapter 20. Server Configuration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="runtime-config-short.html" title="20.18. Short Options">Next</a></td></tr></table><hr /></div><div class="sect1" id="RUNTIME-CONFIG-DEVELOPER"><div class="titlepage"><div><div><h2 class="title" style="clear: both">20.17. Developer Options <a href="#RUNTIME-CONFIG-DEVELOPER" class="id_link">#</a></h2></div></div></div><p>
The following parameters are intended for developer testing, and
should never be used on a production database. However, some of
them can be used to assist with the recovery of severely damaged
databases. As such, they have been excluded from the sample
<code class="filename">postgresql.conf</code> file. Note that many of these
parameters require special source compilation flags to work at all.
</p><div class="variablelist"><dl class="variablelist"><dt id="GUC-ALLOW-IN-PLACE-TABLESPACES"><span class="term"><code class="varname">allow_in_place_tablespaces</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.1.1.3" class="indexterm"></a>
</span> <a href="#GUC-ALLOW-IN-PLACE-TABLESPACES" class="id_link">#</a></dt><dd><p>
Allows tablespaces to be created as directories inside
<code class="filename">pg_tblspc</code>, when an empty location string
is provided to the <code class="command">CREATE TABLESPACE</code> command. This
is intended to allow testing replication scenarios where primary and
standby servers are running on the same machine. Such directories
are likely to confuse backup tools that expect to find only symbolic
links in that location.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-ALLOW-SYSTEM-TABLE-MODS"><span class="term"><code class="varname">allow_system_table_mods</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.2.1.3" class="indexterm"></a>
</span> <a href="#GUC-ALLOW-SYSTEM-TABLE-MODS" class="id_link">#</a></dt><dd><p>
Allows modification of the structure of system tables as well as
certain other risky actions on system tables. This is otherwise not
allowed even for superusers. Ill-advised use of this setting can
cause irretrievable data loss or seriously corrupt the database
system.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-BACKTRACE-FUNCTIONS"><span class="term"><code class="varname">backtrace_functions</code> (<code class="type">string</code>)
<a id="id-1.6.7.20.3.3.1.3" class="indexterm"></a>
</span> <a href="#GUC-BACKTRACE-FUNCTIONS" class="id_link">#</a></dt><dd><p>
This parameter contains a comma-separated list of C function names.
If an error is raised and the name of the internal C function where
the error happens matches a value in the list, then a backtrace is
written to the server log together with the error message. This can
be used to debug specific areas of the source code.
</p><p>
Backtrace support is not available on all platforms, and the quality
of the backtraces depends on compilation options.
</p><p>
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-DEBUG-DISCARD-CACHES"><span class="term"><code class="varname">debug_discard_caches</code> (<code class="type">integer</code>)
<a id="id-1.6.7.20.3.4.1.3" class="indexterm"></a>
</span> <a href="#GUC-DEBUG-DISCARD-CACHES" class="id_link">#</a></dt><dd><p>
When set to <code class="literal">1</code>, each system catalog cache entry is
invalidated at the first possible opportunity, whether or not
anything that would render it invalid really occurred. Caching of
system catalogs is effectively disabled as a result, so the server
will run extremely slowly. Higher values run the cache invalidation
recursively, which is even slower and only useful for testing
the caching logic itself. The default value of <code class="literal">0</code>
selects normal catalog caching behavior.
</p><p>
This parameter can be very helpful when trying to trigger
hard-to-reproduce bugs involving concurrent catalog changes, but it
is otherwise rarely needed. See the source code files
<code class="filename">inval.c</code> and
<code class="filename">pg_config_manual.h</code> for details.
</p><p>
This parameter is supported when
<code class="symbol">DISCARD_CACHES_ENABLED</code> was defined at compile time
(which happens automatically when using the
<span class="application">configure</span> option
<code class="option">--enable-cassert</code>). In production builds, its value
will always be <code class="literal">0</code> and attempts to set it to another
value will raise an error.
</p></dd><dt id="GUC-DEBUG-IO-DIRECT"><span class="term"><code class="varname">debug_io_direct</code> (<code class="type">string</code>)
<a id="id-1.6.7.20.3.5.1.3" class="indexterm"></a>
</span> <a href="#GUC-DEBUG-IO-DIRECT" class="id_link">#</a></dt><dd><p>
Ask the kernel to minimize caching effects for relation data and WAL
files using <code class="literal">O_DIRECT</code> (most Unix-like systems),
<code class="literal">F_NOCACHE</code> (macOS) or
<code class="literal">FILE_FLAG_NO_BUFFERING</code> (Windows).
</p><p>
May be set to an empty string (the default) to disable use of direct
I/O, or a comma-separated list of operations that should use direct I/O.
The valid options are <code class="literal">data</code> for
main data files, <code class="literal">wal</code> for WAL files, and
<code class="literal">wal_init</code> for WAL files when being initially
allocated.
</p><p>
Some operating systems and file systems do not support direct I/O, so
non-default settings may be rejected at startup or cause errors.
</p><p>
Currently this feature reduces performance, and is intended for
developer testing only.
</p></dd><dt id="GUC-DEBUG-PARALLEL-QUERY"><span class="term"><code class="varname">debug_parallel_query</code> (<code class="type">enum</code>)
<a id="id-1.6.7.20.3.6.1.3" class="indexterm"></a>
</span> <a href="#GUC-DEBUG-PARALLEL-QUERY" class="id_link">#</a></dt><dd><p>
Allows the use of parallel queries for testing purposes even in cases
where no performance benefit is expected.
The allowed values of <code class="varname">debug_parallel_query</code> are
<code class="literal">off</code> (use parallel mode only when it is expected to improve
performance), <code class="literal">on</code> (force parallel query for all queries
for which it is thought to be safe), and <code class="literal">regress</code> (like
<code class="literal">on</code>, but with additional behavior changes as explained
below).
</p><p>
More specifically, setting this value to <code class="literal">on</code> will add
a <code class="literal">Gather</code> node to the top of any query plan for which this
appears to be safe, so that the query runs inside of a parallel worker.
Even when a parallel worker is not available or cannot be used,
operations such as starting a subtransaction that would be prohibited
in a parallel query context will be prohibited unless the planner
believes that this will cause the query to fail. If failures or
unexpected results occur when this option is set, some functions used
by the query may need to be marked <code class="literal">PARALLEL UNSAFE</code>
(or, possibly, <code class="literal">PARALLEL RESTRICTED</code>).
</p><p>
Setting this value to <code class="literal">regress</code> has all of the same effects
as setting it to <code class="literal">on</code> plus some additional effects that are
intended to facilitate automated regression testing. Normally,
messages from a parallel worker include a context line indicating that,
but a setting of <code class="literal">regress</code> suppresses this line so that the
output is the same as in non-parallel execution. Also,
the <code class="literal">Gather</code> nodes added to plans by this setting are hidden
in <code class="literal">EXPLAIN</code> output so that the output matches what
would be obtained if this setting were turned <code class="literal">off</code>.
</p></dd><dt id="GUC-IGNORE-SYSTEM-INDEXES"><span class="term"><code class="varname">ignore_system_indexes</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.7.1.3" class="indexterm"></a>
</span> <a href="#GUC-IGNORE-SYSTEM-INDEXES" class="id_link">#</a></dt><dd><p>
Ignore system indexes when reading system tables (but still
update the indexes when modifying the tables). This is useful
when recovering from damaged system indexes.
This parameter cannot be changed after session start.
</p></dd><dt id="GUC-POST-AUTH-DELAY"><span class="term"><code class="varname">post_auth_delay</code> (<code class="type">integer</code>)
<a id="id-1.6.7.20.3.8.1.3" class="indexterm"></a>
</span> <a href="#GUC-POST-AUTH-DELAY" class="id_link">#</a></dt><dd><p>
The amount of time to delay when a new
server process is started, after it conducts the
authentication procedure. This is intended to give developers an
opportunity to attach to the server process with a debugger.
If this value is specified without units, it is taken as seconds.
A value of zero (the default) disables the delay.
This parameter cannot be changed after session start.
</p></dd><dt id="GUC-PRE-AUTH-DELAY"><span class="term"><code class="varname">pre_auth_delay</code> (<code class="type">integer</code>)
<a id="id-1.6.7.20.3.9.1.3" class="indexterm"></a>
</span> <a href="#GUC-PRE-AUTH-DELAY" class="id_link">#</a></dt><dd><p>
The amount of time to delay just after a
new server process is forked, before it conducts the
authentication procedure. This is intended to give developers an
opportunity to attach to the server process with a debugger to
trace down misbehavior in authentication.
If this value is specified without units, it is taken as seconds.
A value of zero (the default) disables the delay.
This parameter can only be set in the <code class="filename">postgresql.conf</code>
file or on the server command line.
</p></dd><dt id="GUC-TRACE-NOTIFY"><span class="term"><code class="varname">trace_notify</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.10.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-NOTIFY" class="id_link">#</a></dt><dd><p>
Generates a great amount of debugging output for the
<code class="command">LISTEN</code> and <code class="command">NOTIFY</code>
commands. <a class="xref" href="runtime-config-client.html#GUC-CLIENT-MIN-MESSAGES">client_min_messages</a> or
<a class="xref" href="runtime-config-logging.html#GUC-LOG-MIN-MESSAGES">log_min_messages</a> must be
<code class="literal">DEBUG1</code> or lower to send this output to the
client or server logs, respectively.
</p></dd><dt id="GUC-TRACE-RECOVERY-MESSAGES"><span class="term"><code class="varname">trace_recovery_messages</code> (<code class="type">enum</code>)
<a id="id-1.6.7.20.3.11.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-RECOVERY-MESSAGES" class="id_link">#</a></dt><dd><p>
Enables logging of recovery-related debugging output that otherwise
would not be logged. This parameter allows the user to override the
normal setting of <a class="xref" href="runtime-config-logging.html#GUC-LOG-MIN-MESSAGES">log_min_messages</a>, but only for
specific messages. This is intended for use in debugging hot standby.
Valid values are <code class="literal">DEBUG5</code>, <code class="literal">DEBUG4</code>,
<code class="literal">DEBUG3</code>, <code class="literal">DEBUG2</code>, <code class="literal">DEBUG1</code>, and
<code class="literal">LOG</code>. The default, <code class="literal">LOG</code>, does not affect
logging decisions at all. The other values cause recovery-related
debug messages of that priority or higher to be logged as though they
had <code class="literal">LOG</code> priority; for common settings of
<code class="varname">log_min_messages</code> this results in unconditionally sending
them to the server log.
This parameter can only be set in the <code class="filename">postgresql.conf</code>
file or on the server command line.
</p></dd><dt id="GUC-TRACE-SORT"><span class="term"><code class="varname">trace_sort</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.12.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-SORT" class="id_link">#</a></dt><dd><p>
If on, emit information about resource usage during sort operations.
This parameter is only available if the <code class="symbol">TRACE_SORT</code> macro
was defined when <span class="productname">PostgreSQL</span> was compiled.
(However, <code class="symbol">TRACE_SORT</code> is currently defined by default.)
</p></dd><dt id="GUC-TRACE-LOCKS"><span class="term"><code class="varname">trace_locks</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.13.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-LOCKS" class="id_link">#</a></dt><dd><p>
If on, emit information about lock usage. Information dumped
includes the type of lock operation, the type of lock and the unique
identifier of the object being locked or unlocked. Also included
are bit masks for the lock types already granted on this object as
well as for the lock types awaited on this object. For each lock
type a count of the number of granted locks and waiting locks is
also dumped as well as the totals. An example of the log file output
is shown here:
</p><pre class="screen">
LOG: LockAcquire: new: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(AccessShareLock)
LOG: GrantLock: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(2) req(1,0,0,0,0,0,0)=1 grant(1,0,0,0,0,0,0)=1
wait(0) type(AccessShareLock)
LOG: UnGrantLock: updated: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(AccessShareLock)
LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1)
grantMask(0) req(0,0,0,0,0,0,0)=0 grant(0,0,0,0,0,0,0)=0
wait(0) type(INVALID)
</pre><p>
Details of the structure being dumped may be found in
<code class="filename">src/include/storage/lock.h</code>.
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-TRACE-LWLOCKS"><span class="term"><code class="varname">trace_lwlocks</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.14.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-LWLOCKS" class="id_link">#</a></dt><dd><p>
If on, emit information about lightweight lock usage. Lightweight
locks are intended primarily to provide mutual exclusion of access
to shared-memory data structures.
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-TRACE-USERLOCKS"><span class="term"><code class="varname">trace_userlocks</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.15.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-USERLOCKS" class="id_link">#</a></dt><dd><p>
If on, emit information about user lock usage. Output is the same
as for <code class="symbol">trace_locks</code>, only for advisory locks.
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-TRACE-LOCK-OIDMIN"><span class="term"><code class="varname">trace_lock_oidmin</code> (<code class="type">integer</code>)
<a id="id-1.6.7.20.3.16.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-LOCK-OIDMIN" class="id_link">#</a></dt><dd><p>
If set, do not trace locks for tables below this OID (used to avoid
output on system tables).
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-TRACE-LOCK-TABLE"><span class="term"><code class="varname">trace_lock_table</code> (<code class="type">integer</code>)
<a id="id-1.6.7.20.3.17.1.3" class="indexterm"></a>
</span> <a href="#GUC-TRACE-LOCK-TABLE" class="id_link">#</a></dt><dd><p>
Unconditionally trace locks on this table (OID).
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-DEBUG-DEADLOCKS"><span class="term"><code class="varname">debug_deadlocks</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.18.1.3" class="indexterm"></a>
</span> <a href="#GUC-DEBUG-DEADLOCKS" class="id_link">#</a></dt><dd><p>
If set, dumps information about all current locks when a
deadlock timeout occurs.
</p><p>
This parameter is only available if the <code class="symbol">LOCK_DEBUG</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-LOG-BTREE-BUILD-STATS"><span class="term"><code class="varname">log_btree_build_stats</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.19.1.3" class="indexterm"></a>
</span> <a href="#GUC-LOG-BTREE-BUILD-STATS" class="id_link">#</a></dt><dd><p>
If set, logs system resource usage statistics (memory and CPU) on
various B-tree operations.
</p><p>
This parameter is only available if the <code class="symbol">BTREE_BUILD_STATS</code>
macro was defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-WAL-CONSISTENCY-CHECKING"><span class="term"><code class="varname">wal_consistency_checking</code> (<code class="type">string</code>)
<a id="id-1.6.7.20.3.20.1.3" class="indexterm"></a>
</span> <a href="#GUC-WAL-CONSISTENCY-CHECKING" class="id_link">#</a></dt><dd><p>
This parameter is intended to be used to check for bugs in the WAL
redo routines. When enabled, full-page images of any buffers modified
in conjunction with the WAL record are added to the record.
If the record is subsequently replayed, the system will first apply
each record and then test whether the buffers modified by the record
match the stored images. In certain cases (such as hint bits), minor
variations are acceptable, and will be ignored. Any unexpected
differences will result in a fatal error, terminating recovery.
</p><p>
The default value of this setting is the empty string, which disables
the feature. It can be set to <code class="literal">all</code> to check all
records, or to a comma-separated list of resource managers to check
only records originating from those resource managers. Currently,
the supported resource managers are <code class="literal">heap</code>,
<code class="literal">heap2</code>, <code class="literal">btree</code>, <code class="literal">hash</code>,
<code class="literal">gin</code>, <code class="literal">gist</code>, <code class="literal">sequence</code>,
<code class="literal">spgist</code>, <code class="literal">brin</code>, and <code class="literal">generic</code>.
Extensions may define additional resource managers. Only superusers and users with
the appropriate <code class="literal">SET</code> privilege can change this setting.
</p></dd><dt id="GUC-WAL-DEBUG"><span class="term"><code class="varname">wal_debug</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.21.1.3" class="indexterm"></a>
</span> <a href="#GUC-WAL-DEBUG" class="id_link">#</a></dt><dd><p>
If on, emit WAL-related debugging output. This parameter is
only available if the <code class="symbol">WAL_DEBUG</code> macro was
defined when <span class="productname">PostgreSQL</span> was
compiled.
</p></dd><dt id="GUC-IGNORE-CHECKSUM-FAILURE"><span class="term"><code class="varname">ignore_checksum_failure</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.22.1.3" class="indexterm"></a>
</span> <a href="#GUC-IGNORE-CHECKSUM-FAILURE" class="id_link">#</a></dt><dd><p>
Only has effect if <a class="xref" href="app-initdb.html#APP-INITDB-DATA-CHECKSUMS">data checksums</a> are enabled.
</p><p>
Detection of a checksum failure during a read normally causes
<span class="productname">PostgreSQL</span> to report an error, aborting the current
transaction. Setting <code class="varname">ignore_checksum_failure</code> to on causes
the system to ignore the failure (but still report a warning), and
continue processing. This behavior may <span class="emphasis"><em>cause crashes, propagate
or hide corruption, or other serious problems</em></span>. However, it may allow
you to get past the error and retrieve undamaged tuples that might still be
present in the table if the block header is still sane. If the header is
corrupt an error will be reported even if this option is enabled. The
default setting is <code class="literal">off</code>.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-ZERO-DAMAGED-PAGES"><span class="term"><code class="varname">zero_damaged_pages</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.23.1.3" class="indexterm"></a>
</span> <a href="#GUC-ZERO-DAMAGED-PAGES" class="id_link">#</a></dt><dd><p>
Detection of a damaged page header normally causes
<span class="productname">PostgreSQL</span> to report an error, aborting the current
transaction. Setting <code class="varname">zero_damaged_pages</code> to on causes
the system to instead report a warning, zero out the damaged
page in memory, and continue processing. This behavior <span class="emphasis"><em>will destroy data</em></span>,
namely all the rows on the damaged page. However, it does allow you to get
past the error and retrieve rows from any undamaged pages that might
be present in the table. It is useful for recovering data if
corruption has occurred due to a hardware or software error. You should
generally not set this on until you have given up hope of recovering
data from the damaged pages of a table. Zeroed-out pages are not
forced to disk so it is recommended to recreate the table or
the index before turning this parameter off again. The
default setting is <code class="literal">off</code>.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-IGNORE-INVALID-PAGES"><span class="term"><code class="varname">ignore_invalid_pages</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.24.1.3" class="indexterm"></a>
</span> <a href="#GUC-IGNORE-INVALID-PAGES" class="id_link">#</a></dt><dd><p>
If set to <code class="literal">off</code> (the default), detection of
WAL records having references to invalid pages during
recovery causes <span class="productname">PostgreSQL</span> to
raise a PANIC-level error, aborting the recovery. Setting
<code class="varname">ignore_invalid_pages</code> to <code class="literal">on</code>
causes the system to ignore invalid page references in WAL records
(but still report a warning), and continue the recovery.
This behavior may <span class="emphasis"><em>cause crashes, data loss,
propagate or hide corruption, or other serious problems</em></span>.
However, it may allow you to get past the PANIC-level error,
to finish the recovery, and to cause the server to start up.
The parameter can only be set at server start. It only has effect
during recovery or in standby mode.
</p></dd><dt id="GUC-JIT-DEBUGGING-SUPPORT"><span class="term"><code class="varname">jit_debugging_support</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.25.1.3" class="indexterm"></a>
</span> <a href="#GUC-JIT-DEBUGGING-SUPPORT" class="id_link">#</a></dt><dd><p>
If LLVM has the required functionality, register generated functions
with <span class="productname">GDB</span>. This makes debugging easier.
The default setting is <code class="literal">off</code>.
This parameter can only be set at server start.
</p></dd><dt id="GUC-JIT-DUMP-BITCODE"><span class="term"><code class="varname">jit_dump_bitcode</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.26.1.3" class="indexterm"></a>
</span> <a href="#GUC-JIT-DUMP-BITCODE" class="id_link">#</a></dt><dd><p>
Writes the generated <span class="productname">LLVM</span> IR out to the
file system, inside <a class="xref" href="runtime-config-file-locations.html#GUC-DATA-DIRECTORY">data_directory</a>. This is only
useful for working on the internals of the JIT implementation.
The default setting is <code class="literal">off</code>.
Only superusers and users with the appropriate <code class="literal">SET</code>
privilege can change this setting.
</p></dd><dt id="GUC-JIT-EXPRESSIONS"><span class="term"><code class="varname">jit_expressions</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.27.1.3" class="indexterm"></a>
</span> <a href="#GUC-JIT-EXPRESSIONS" class="id_link">#</a></dt><dd><p>
Determines whether expressions are JIT compiled, when JIT compilation
is activated (see <a class="xref" href="jit-decision.html" title="32.2. When to JIT?">Section 32.2</a>). The default is
<code class="literal">on</code>.
</p></dd><dt id="GUC-JIT-PROFILING-SUPPORT"><span class="term"><code class="varname">jit_profiling_support</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.28.1.3" class="indexterm"></a>
</span> <a href="#GUC-JIT-PROFILING-SUPPORT" class="id_link">#</a></dt><dd><p>
If LLVM has the required functionality, emit the data needed to allow
<span class="productname">perf</span> to profile functions generated by JIT.
This writes out files to <code class="filename">~/.debug/jit/</code>; the
user is responsible for performing cleanup when desired.
The default setting is <code class="literal">off</code>.
This parameter can only be set at server start.
</p></dd><dt id="GUC-JIT-TUPLE-DEFORMING"><span class="term"><code class="varname">jit_tuple_deforming</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.29.1.3" class="indexterm"></a>
</span> <a href="#GUC-JIT-TUPLE-DEFORMING" class="id_link">#</a></dt><dd><p>
Determines whether tuple deforming is JIT compiled, when JIT
compilation is activated (see <a class="xref" href="jit-decision.html" title="32.2. When to JIT?">Section 32.2</a>).
The default is <code class="literal">on</code>.
</p></dd><dt id="GUC-REMOVE-TEMP-FILES-AFTER-CRASH"><span class="term"><code class="varname">remove_temp_files_after_crash</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.30.1.3" class="indexterm"></a>
</span> <a href="#GUC-REMOVE-TEMP-FILES-AFTER-CRASH" class="id_link">#</a></dt><dd><p>
When set to <code class="literal">on</code>, which is the default,
<span class="productname">PostgreSQL</span> will automatically remove
temporary files after a backend crash. If disabled, the files will be
retained and may be used for debugging, for example. Repeated crashes
may however result in accumulation of useless files. This parameter
can only be set in the <code class="filename">postgresql.conf</code> file or on
the server command line.
</p></dd><dt id="GUC-SEND-ABORT-FOR-CRASH"><span class="term"><code class="varname">send_abort_for_crash</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.31.1.3" class="indexterm"></a>
</span> <a href="#GUC-SEND-ABORT-FOR-CRASH" class="id_link">#</a></dt><dd><p>
By default, after a backend crash the postmaster will stop remaining
child processes by sending them <span class="systemitem">SIGQUIT</span>
signals, which permits them to exit more-or-less gracefully. When
this option is set to <code class="literal">on</code>,
<span class="systemitem">SIGABRT</span> is sent instead. That normally
results in production of a core dump file for each such child
process.
This can be handy for investigating the states of other processes
after a crash. It can also consume lots of disk space in the event
of repeated crashes, so do not enable this on systems you are not
monitoring carefully.
Beware that no support exists for cleaning up the core file(s)
automatically.
This parameter can only be set in
the <code class="filename">postgresql.conf</code> file or on the server
command line.
</p></dd><dt id="GUC-SEND-ABORT-FOR-KILL"><span class="term"><code class="varname">send_abort_for_kill</code> (<code class="type">boolean</code>)
<a id="id-1.6.7.20.3.32.1.3" class="indexterm"></a>
</span> <a href="#GUC-SEND-ABORT-FOR-KILL" class="id_link">#</a></dt><dd><p>
By default, after attempting to stop a child process with
<span class="systemitem">SIGQUIT</span>, the postmaster will wait five
seconds and then send <span class="systemitem">SIGKILL</span> to force
immediate termination. When this option is set
to <code class="literal">on</code>, <span class="systemitem">SIGABRT</span> is sent
instead of <span class="systemitem">SIGKILL</span>. That normally results
in production of a core dump file for each such child process.
This can be handy for investigating the states
of <span class="quote">“<span class="quote">stuck</span>”</span> child processes. It can also consume lots
of disk space in the event of repeated crashes, so do not enable
this on systems you are not monitoring carefully.
Beware that no support exists for cleaning up the core file(s)
automatically.
This parameter can only be set in
the <code class="filename">postgresql.conf</code> file or on the server
command line.
</p></dd><dt id="GUC-DEBUG-LOGICAL-REPLICATION-STREAMING"><span class="term"><code class="varname">debug_logical_replication_streaming</code> (<code class="type">enum</code>)
<a id="id-1.6.7.20.3.33.1.3" class="indexterm"></a>
</span> <a href="#GUC-DEBUG-LOGICAL-REPLICATION-STREAMING" class="id_link">#</a></dt><dd><p>
The allowed values are <code class="literal">buffered</code> and
<code class="literal">immediate</code>. The default is <code class="literal">buffered</code>.
This parameter is intended to be used to test logical decoding and
replication of large transactions. The effect of
<code class="varname">debug_logical_replication_streaming</code> is different for the
publisher and subscriber:
</p><p>
On the publisher side, <code class="varname">debug_logical_replication_streaming</code>
allows streaming or serializing changes immediately in logical decoding.
When set to <code class="literal">immediate</code>, stream each change if the
<a class="link" href="sql-createsubscription.html#SQL-CREATESUBSCRIPTION-WITH-STREAMING"><code class="literal">streaming</code></a>
option of
<a class="link" href="sql-createsubscription.html" title="CREATE SUBSCRIPTION"><code class="command">CREATE SUBSCRIPTION</code></a>
is enabled, otherwise, serialize each change. When set to
<code class="literal">buffered</code>, the decoding will stream or serialize
changes when <code class="varname">logical_decoding_work_mem</code> is reached.
</p><p>
On the subscriber side, if the <code class="literal">streaming</code> option is set to
<code class="literal">parallel</code>, <code class="varname">debug_logical_replication_streaming</code>
can be used to direct the leader apply worker to send changes to the
shared memory queue or to serialize all changes to the file. When set to
<code class="literal">buffered</code>, the leader sends changes to parallel apply
workers via a shared memory queue. When set to
<code class="literal">immediate</code>, the leader serializes all changes to files
and notifies the parallel apply workers to read and apply them at the
end of the transaction.
</p></dd></dl></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="runtime-config-custom.html" title="20.16. Customized Options">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="runtime-config.html" title="Chapter 20. Server Configuration">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="runtime-config-short.html" title="20.18. Short Options">Next</a></td></tr><tr><td width="40%" align="left" valign="top">20.16. Customized Options </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.3 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 20.18. Short Options</td></tr></table></div></body></html>