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
<filename>postgresql.conf</filename> file. Note that many of these
parameters require special source compilation flags to work at all.
以下のパラメータは、開発者のテスト用であり、決して実運用のデータベースに使わないでください。
しかし、中には深刻な損傷を負ったデータベースの復旧に役立つものもあります。
したがって、これらはサンプルのpostgresql.conf
からは除外されています。
これらのパラメータの多くは、それを動作させるために特殊なソースコンパイルを必要としていることに注意してください。
allow_in_place_tablespaces
(boolean
)
#
Allows tablespaces to be created as directories inside
<filename>pg_tblspc</filename>, when an empty location string
is provided to the <command>CREATE TABLESPACE</command> 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 <literal>SET</literal>
privilege can change this setting.
CREATE TABLESPACE
コマンドに空の位置文字列が渡された時に、pg_tblspc
内にテーブル空間をディレクトリとして作ることを可能にします。
これは、プライマリとスタンバイサーバが同じマシン上で実行されるレプリケーションシナリオをテストするために使用することを意図しています。
このようなディレクトリは、その場所にシンボリックリンクだけが見つかることを期待しているバックアップツールを混乱させる可能性が高いでしょう。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
allow_system_table_mods
(boolean
)
#
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 <literal>SET</literal>
privilege can change this setting.
システムテーブルの構造変更とその他の危険性の高いシステムテーブルに対するアクションを許可します。
これは通常スーパーユーザにさえ許可されません。
この設定の無分別な使用は回復不能なデータ喪失やデータベースシステムの重大な破損を招きます。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
backtrace_functions
(string
)
#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. このパラメータはカンマ区切りのC関数名を含みます。 エラーが発生し、エラー発生箇所の内部C関数がこのリストの値と一致すると、エラーメッセージとともにバックトレースが一緒にサーバログに書かれます。 これはソースコードの特定箇所をデバッグするのに役立ちます。
Backtrace support is not available on all platforms, and the quality of the backtraces depends on compilation options. バックトレースのサポートはすべてのプラットフォームで提供されているわけではありませんし、バックトレースの品質はコンパイルオプションに依存します。
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
この設定を変更できるのは、スーパーユーザと適切なSET
権限を持つユーザだけです。
debug_discard_caches
(integer
)
#
When set to <literal>1</literal>, 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 <literal>0</literal>
selects normal catalog caching behavior.
1
なら、可能な最初の機会にシステムカタログのキャッシュ項目が破棄されます。
すべてのキャッシュ項目を無効にするすべてのことが実際に起きます。
結果としてシステムカタログのキャッシュが無効になり、サーバは極めて低速に動作します。
1より大きければ、再帰的にキャッシュを削除します。
これは更に遅くなり、キャッシュのロジック自体をテストするときにだけ役に立ちます。
デフォルト値の0
で正常なカタログキャッシュは通常の動作になります。
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
<filename>inval.c</filename> and
<filename>pg_config_manual.h</filename> for details.
このパラメータは並行的なカタログの変更を伴う再現しにくいバグを引き起こす際にとても役に立ちますが、それ以外にはめったに必要になりません。
詳細はinval.c
とpg_config_manual.h
のソースコードファイルを見てください。
This parameter is supported when
<symbol>DISCARD_CACHES_ENABLED</symbol> was defined at compile time
(which happens automatically when using the
<application>configure</application> option
<option>--enable-cassert</option>). In production builds, its value
will always be <literal>0</literal> and attempts to set it to another
value will raise an error.
このパラメータはコンパイル時にDISCARD_CACHES_ENABLED
が定義されたとき(これはconfigureオプションの--enable-cassert
が使われたときに自動的に起こります)にサポートされます。
実運用のビルドでは0
となり、それ以外の値に設定しようとするとエラーが起こります。
debug_io_direct
(string
)
#
Ask the kernel to minimize caching effects for relation data and WAL
files using <literal>O_DIRECT</literal> (most Unix-like systems),
<literal>F_NOCACHE</literal> (macOS) or
<literal>FILE_FLAG_NO_BUFFERING</literal> (Windows).
リレーションデータとWALファイルに対して、O_DIRECT
(ほとんどのUnixライクなシステム)、F_NOCACHE
(macOS)、FILE_FLAG_NO_BUFFERING
(Windows)を使って、キャッシュ効果を最小にするようカーネルに依頼します。
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 <literal>data</literal> for
main data files, <literal>wal</literal> for WAL files, and
<literal>wal_init</literal> for WAL files when being initially
allocated.
空文字列(デフォルト)を設定してダイレクトI/Oの使用を無効にすることも、カンマで区切られたリストを設定してダイレクトI/Oを使用するようにすることもできます。
有効なオプションは、メインデータファイルの場合はdata
、WALファイルの場合はwal
、最初に割り当てられたWALファイルの場合はwal_init
です。
Some operating systems and file systems do not support direct I/O, so non-default settings may be rejected at startup or cause errors. 一部のオペレーティングシステムおよびファイルシステムでは、ダイレクトI/Oが行われないため、デフォルト以外の設定が起動時に拒否されたり、エラーが発生したりする場合があります。
Currently this feature reduces performance, and is intended for developer testing only. 今の所、この機能はパフォーマンスを悪くするので、開発者のテストのみを目的としています。
debug_parallel_query
(enum
)
#
Allows the use of parallel queries for testing purposes even in cases
where no performance benefit is expected.
The allowed values of <varname>debug_parallel_query</varname> are
<literal>off</literal> (use parallel mode only when it is expected to improve
performance), <literal>on</literal> (force parallel query for all queries
for which it is thought to be safe), and <literal>regress</literal> (like
<literal>on</literal>, but with additional behavior changes as explained
below).
性能改善が期待できなくても、テスト目的のためにパラレルクエリを利用できるようにします。
debug_parallel_query
に設定できる値は、off
(性能改善が期待できるときにだけパラレルクエリを使用する)、on
(安全なクエリに対しては常にパラレルクエリを強制する)、regress
(on
と同様だが、下記のような振る舞いの変更を伴う)です。
More specifically, setting this value to <literal>on</literal> will add
a <literal>Gather</literal> 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 <literal>PARALLEL UNSAFE</literal>
(or, possibly, <literal>PARALLEL RESTRICTED</literal>).
正確に言えば、この値をon
にすると、安全と見なされるすべての問い合わせ計画の上にGather
ノードを追加し、クエリをパラレルワーカー上で実行するようにします。
プランナがこれによってクエリが失敗すると思わない限り、パラレルワーカーが利用できない、あるいは使用できないような場合でも、たとえばサブトランザクションの開始のように、パラレルクエリコンテキストでは許可されない操作は不許可となります。
このオプションを設定することによって、エラーとなったり、あるいは期待していなかった結果がもたらされる場合には、クエリで使用されている関数はPARALLEL UNSAFE
(もしくは、PARALLEL RESTRICTED
)と印を付ける必要があるかもしません。
Setting this value to <literal>regress</literal> has all of the same effects
as setting it to <literal>on</literal> 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 <literal>regress</literal> suppresses this line so that the
output is the same as in non-parallel execution. Also,
the <literal>Gather</literal> nodes added to plans by this setting are hidden
in <literal>EXPLAIN</literal> output so that the output matches what
would be obtained if this setting were turned <literal>off</literal>.
この設定値をregress
とすると、on
とするのに加え、自動リグレッションテストを助けるための付加的な効果が現れます。
通常パラレルワーカーからのメッセージは、そのことを表すコンテキスト行を表示しますが、regress
と設定すると、非パラレル実行と同じ出力になるように、これを抑止します。
また、プランに追加されたGather
ノードは、EXPLAIN
出力から隠され、off
に設定したときと同じ出力が得られるようにします。
ignore_system_indexes
(boolean
)
#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. システムテーブルの読み込み時にシステムインデックスを無視します(しかしテーブルが更新された時はインデックスを更新します)。 障害があるシステムインデックスを復旧する時、これは有用です。 セッションが始まった後に、このパラメータを変更することはできません。
post_auth_delay
(integer
)
#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. サーバプロセスが始まり認証手続きが終わった後の遅延時間です。 これは、デバッガを使用してサーバプロセスに接続する機会を開発者に提供することを目的としています。 この値が単位なしで指定された場合は、秒単位であるとみなします。 値がゼロ(デフォルト)の場合、この遅延は無効になります。 セッションが始まった後に、このパラメータを変更することはできません。
pre_auth_delay
(integer
)
#
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 <filename>postgresql.conf</filename>
file or on the server command line.
新しくサーバプロセスがforkした後、認証手続きに入る前の遅延時間です。
これは、認証における誤動作を追跡するために、デバッガを使用してサーバプロセスに接続する機会を開発者に提供することを目的としたものです。
この値が単位なしで指定された場合は、秒単位であるとみなします。
値がゼロ(デフォルト)の場合、この機能は無効になります。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
trace_notify
(boolean
)
#
Generates a great amount of debugging output for the
<command>LISTEN</command> and <command>NOTIFY</command>
commands. <xref linkend="guc-client-min-messages"/> or
<xref linkend="guc-log-min-messages"/> must be
<literal>DEBUG1</literal> or lower to send this output to the
client or server logs, respectively.
LISTEN
とNOTIFY
コマンドのための大量なデバッグ出力を生成します。
この出力をクライアントもしくはサーバログに送信するためには、それぞれ、client_min_messagesもしくはlog_min_messagesはDEBUG1
以下でなければなりません。
trace_sort
(boolean
)
#
If on, emit information about resource usage during sort operations.
This parameter is only available if the <symbol>TRACE_SORT</symbol> macro
was defined when <productname>PostgreSQL</productname> was compiled.
(However, <symbol>TRACE_SORT</symbol> is currently defined by default.)
もしも有効であれば、並べ替え操作の間のリソース使用についての情報を放出します。
このパラメータは PostgreSQLがコンパイルされた時、TRACE_SORT
マクロが定義されている場合にのみ有効です。
(とは言っても、現在TRACE_SORT
はデフォルトで定義されています。)
trace_locks
(boolean
)
#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: 有効な場合、ロックの使用状況に関する情報を出力します。 出力される情報には、ロック操作の種類、ロックの種類、ロックまたはロック解除されているオブジェクトの一意な識別子が含まれます。 また、このオブジェクトに既に与えられているロック種類やこのオブジェクトで待機しているロック種類を表すビットマスクも含まれます。 ロック種類それぞれについて、与えられているロック数、待機中のロック数がその総数と共に出力されます。 ログファイル出力例を以下に示します。
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)
Details of the structure being dumped may be found in
<filename>src/include/storage/lock.h</filename>.
ダンプされる構造の詳細は、src/include/storage/lock.h
にあります。
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
trace_lwlocks
(boolean
)
#If on, emit information about lightweight lock usage. Lightweight locks are intended primarily to provide mutual exclusion of access to shared-memory data structures. 有効な場合、軽量ロックの使用状況に関する情報を出力します。 軽量ロックは主に、共有メモリ上のデータ構造へのアクセスに関する排他制御機能を提供することを意図したものです。
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
trace_userlocks
(boolean
)
#
If on, emit information about user lock usage. Output is the same
as for <symbol>trace_locks</symbol>, only for advisory locks.
有効な場合、ユーザロックの使用状況に関する情報を出力します。
出力はtrace_locks
と同じですが、勧告的ロックに関するもののみを出力します。
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
trace_lock_oidmin
(integer
)
#If set, do not trace locks for tables below this OID (used to avoid output on system tables). 設定すると、このOID未満のテーブルに関するロックの追跡を行いません。 (システムテーブルに関する出力を抑えるために使用します。)
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
trace_lock_table
(integer
)
#Unconditionally trace locks on this table (OID). このテーブル(OID)に対し無条件でロックを追跡します。
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
debug_deadlocks
(boolean
)
#If set, dumps information about all current locks when a deadlock timeout occurs. 設定すると、デッドロックタイムアウトが発生した時全ての進行中のロックについての情報がダンプされます。
This parameter is only available if the <symbol>LOCK_DEBUG</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にLOCK_DEBUG
マクロが定義された場合のみ有効です。
log_btree_build_stats
(boolean
)
#If set, logs system resource usage statistics (memory and CPU) on various B-tree operations. 設定すると、各種B-tree操作に関するシステムリソース(メモリとCPU)の使用についての統計情報をログに出力します。
This parameter is only available if the <symbol>BTREE_BUILD_STATS</symbol>
macro was defined when <productname>PostgreSQL</productname> was
compiled.
このパラメータはPostgreSQLがコンパイル時にBTREE_BUILD_STATS
マクロが定義された場合のみ有効です。
wal_consistency_checking
(string
)
#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. このパラメータは、WALのREDOルーチンのバグをチェックするために使うことを意図しています。 有効にすると、WALレコードと一緒に変更されたバッファのフルページイメージをレコードに追加します。 後でそのレコードがリプレイされるときは、システムはまず各々のレコードを適用し、次にレコードによって変更されたバッファが、格納したイメージと一致するかどうかをテストします。 ある種のケース(たとえばヒントビット)では、些細な変化は許容され、無視されます。 予期しない差異は、致命的エラーを引き起こし、リカバリが中断されます。
The default value of this setting is the empty string, which disables
the feature. It can be set to <literal>all</literal> 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 <literal>heap</literal>,
<literal>heap2</literal>, <literal>btree</literal>, <literal>hash</literal>,
<literal>gin</literal>, <literal>gist</literal>, <literal>sequence</literal>,
<literal>spgist</literal>, <literal>brin</literal>, and <literal>generic</literal>.
Extensions may define additional resource managers. Only superusers and users with
the appropriate <literal>SET</literal> privilege can change this setting.
デフォルト値は空文字で、この機能を無効にします。
すべてのレコードをチェックするために、all
にすることができます。
カンマ区切りのリストにすると、対応するリソースマネージャに由来するレコードのみをチェックします。
今のところ、サポートされているリソースマネージャは、heap
、heap2
、btree
、hash
、gin
、gist
、sequence
、spgist
、brin
、generic
です。
拡張は追加のリソースマネージャを定義しても構いません。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
wal_debug
(boolean
)
#
If on, emit WAL-related debugging output. This parameter is
only available if the <symbol>WAL_DEBUG</symbol> macro was
defined when <productname>PostgreSQL</productname> was
compiled.
もしonであれば、WALに関連したデバッグ出力が有効になります。このパラメータはWAL_DEBUG
マクロが PostgreSQLのコンパイルの時に定義された場合にのみ有効です。
ignore_checksum_failure
(boolean
)
#Only has effect if <xref linkend="app-initdb-data-checksums"/> are enabled. data checksumsが有効の時のみ効果があります。
Detection of a checksum failure during a read normally causes
<productname>PostgreSQL</productname> to report an error, aborting the current
transaction. Setting <varname>ignore_checksum_failure</varname> to on causes
the system to ignore the failure (but still report a warning), and
continue processing. This behavior may <emphasis>cause crashes, propagate
or hide corruption, or other serious problems</emphasis>. 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 <literal>off</literal>.
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
読み込み過程でチェックサム障害が検出されると、通常PostgreSQLはエラーを報告し、現時点のトランザクションを停止します。
ignore_checksum_failure
を有効(on)に設定するとシステムはその障害を無視し(しかし警告は報告をします)、処理を継続します。
この振る舞いはたぶんクラッシュの原因、破損の伝播や隠ぺい、もしくはその他の深刻な問題の原因になることがあります。
とは言っても、エラーを切り抜け、ブロックヘッダが健全に存在するテーブルにある障害を受けていないタプルの回収は行えます。
もしヘッダが破損されたら、オプションが有効になっていたとしても報告はなされます。
デフォルトの設定はoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
zero_damaged_pages
(boolean
)
#
Detection of a damaged page header normally causes
<productname>PostgreSQL</productname> to report an error, aborting the current
transaction. Setting <varname>zero_damaged_pages</varname> to on causes
the system to instead report a warning, zero out the damaged
page in memory, and continue processing. This behavior <emphasis>will destroy data</emphasis>,
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 <literal>off</literal>.
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
ページヘッダの障害がわかると、通常PostgreSQLはエラーの報告を行い、現在のトランザクションを中断させます。
zero_damaged_pages
をonに設定することにより、システムは代わりに警告を報告し、障害のあるメモリ内のページをゼロで埋め、処理を継続します。
この動作により、障害のあったページ上にある全ての行のデータが破壊されます。
しかし、これによりエラーを確実に無視し、正常なページに存在するテーブル内の行を取り出すことができます。
ハードウェアまたはソフトウェアのエラーによって破損が発生した場合のデータの復旧時に有用です。
障害のあるページからのテーブルのデータの復旧をあきらめた場合を除き、通常はこれをonにしてはいけません。
ゼロで埋められたページはディスクに書き込みを強要されないため、このパラメータを再び無効にする以前にテーブル、またはインデックスを再作成することを勧めます。
デフォルトはoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
ignore_invalid_pages
(boolean
)
#
If set to <literal>off</literal> (the default), detection of
WAL records having references to invalid pages during
recovery causes <productname>PostgreSQL</productname> to
raise a PANIC-level error, aborting the recovery. Setting
<varname>ignore_invalid_pages</varname> to <literal>on</literal>
causes the system to ignore invalid page references in WAL records
(but still report a warning), and continue the recovery.
This behavior may <emphasis>cause crashes, data loss,
propagate or hide corruption, or other serious problems</emphasis>.
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.
off
(デフォルトです)に設定すると、無効なページを参照しているWALレコードはPostgreSQLに対してPANICレベルのエラーを引き起こし、リカバリをアボートします。
ignore_invalid_pages
をon
に設定すると、WALレコードの無効なページへの参照を無視し(しかしワーニングは報告されます)、リカバリを継続します。
この振る舞いにより、クラッシュ、データロス、破壊を増長したり見えなくするなどの深刻な問題を被るかもしれません。
しかし、これによってPANICレベルのエラーを回避してリカバリを完了し、サーバを起動できるかもしれません。
このパラメータはサーバ起動時にのみ設定できます。
リカバリ中、あるいはスタンバイモードでのみ効果があります。
jit_debugging_support
(boolean
)
#
If LLVM has the required functionality, register generated functions
with <productname>GDB</productname>. This makes debugging easier.
The default setting is <literal>off</literal>.
This parameter can only be set at server start.
LLVMに要求された機能がある場合は、生成した関数をGDB用に登録します。
これにより、デバッグが容易になります。
デフォルト設定はoff
です。
このパラメータはサーバ起動時のみ設定可能です。
jit_dump_bitcode
(boolean
)
#
Writes the generated <productname>LLVM</productname> IR out to the
file system, inside <xref linkend="guc-data-directory"/>. This is only
useful for working on the internals of the JIT implementation.
The default setting is <literal>off</literal>.
Only superusers and users with the appropriate <literal>SET</literal>
privilege can change this setting.
生成されたLLVM IRをdata_directory内のファイルシステムに出力します。
これはJITコンパイルのインターナルについて作業するときだけ有用です。
デフォルト設定はoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
jit_expressions
(boolean
)
#
Determines whether expressions are JIT compiled, when JIT compilation
is activated (see <xref linkend="jit-decision"/>). The default is
<literal>on</literal>.
JITコンパイルが有効な時に式がJITコンパイルされるかどうかを決定します。
(30.2参照。)
デフォルトはon
です。
jit_profiling_support
(boolean
)
#
If LLVM has the required functionality, emit the data needed to allow
<productname>perf</productname> to profile functions generated by JIT.
This writes out files to <filename>~/.debug/jit/</filename>; the
user is responsible for performing cleanup when desired.
The default setting is <literal>off</literal>.
This parameter can only be set at server start.
LLVMに要求された機能がある場合は、JITが生成した関数をperfでプロファイルすることができるデータを出力します。
これにより~/.debug/jit/
にファイルが書き出されます。
ユーザは自分の責任で必要なときに後始末を行わなければなりません。
デフォルト設定はoff
です。
このパラメータはサーバ起動時のみ設定可能です。
jit_tuple_deforming
(boolean
)
#
Determines whether tuple deforming is JIT compiled, when JIT
compilation is activated (see <xref linkend="jit-decision"/>).
The default is <literal>on</literal>.
JITコンパイルが有効な時にタプルデフォーミングがJITコンパイルされるかどうかを決定します。
(30.2参照。)
デフォルトはon
です。
remove_temp_files_after_crash
(boolean
)
#
When set to <literal>on</literal>, which is the default,
<productname>PostgreSQL</productname> 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 <filename>postgresql.conf</filename> file or on
the server command line.
デフォルトであるon
に設定すると、PostgreSQLはバックエンドがクラッシュした後に自動的に一時ファイルを削除します。
無効にすると、ファイルは保存され、たとえばデバッグ目的で使用できます。
しかしクラッシュを繰り返すと不要なファイルが溜まっていくかもしれません。
このパラメータはpostgresql.conf
ファイル内、またはサーバのコマンドラインのみで設定可能です。
send_abort_for_crash
(boolean
)
#
By default, after a backend crash the postmaster will stop remaining
child processes by sending them <systemitem>SIGQUIT</systemitem>
signals, which permits them to exit more-or-less gracefully. When
this option is set to <literal>on</literal>,
<systemitem>SIGABRT</systemitem> 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 <filename>postgresql.conf</filename> file or on the server
command line.
デフォルトでは、バックエンドクラッシュの後、postmasterは残りの子プロセスをSIGQUITシグナルを送ることで停止します。
これにより、子プロセスは多かれ少なかれ礼儀正しく終了することができます。
このオプションがon
に設定されている場合、代わりにSIGABRTが送信されます。
これにより通常、子プロセスごとにコアダンプファイルを生成します。
これは、クラッシュの後の他のプロセスの状態を調査するのに便利です。
また、クラッシュが繰り返されるイベントで大量のディスクスペースを消費する可能性があるため、注意深く監視していないシステムではこれを有効にしないでください。
自動的にコアファイルを削除する機能は提供されていないことに注意してください。
このパラメータはpostgresql.conf
ファイルまたはサーバコマンドラインでのみ設定できます。
send_abort_for_kill
(boolean
)
#
By default, after attempting to stop a child process with
<systemitem>SIGQUIT</systemitem>, the postmaster will wait five
seconds and then send <systemitem>SIGKILL</systemitem> to force
immediate termination. When this option is set
to <literal>on</literal>, <systemitem>SIGABRT</systemitem> is sent
instead of <systemitem>SIGKILL</systemitem>. That normally results
in production of a core dump file for each such child process.
This can be handy for investigating the states
of <quote>stuck</quote> 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 <filename>postgresql.conf</filename> file or on the server
command line.
デフォルトでは、SIGQUITで子プロセスを停止しようとした後、postmasterは5秒間待ってからSIGKILLを送信して即時終了を強制します。
このオプションがon
に設定されている場合、SIGKILLの代わりにSIGABRTが送信されます。
これにより通常、子プロセスごとにコアダンプファイルを生成します。
これは、「スタックした」子プロセスの状態を調査するのに便利です。
また、クラッシュが繰り返されるイベントで大量のディスクスペースを消費する可能性があるため、注意深く監視していないシステムではこれを有効にしないでください。
自動的にコアファイルを削除する機能は提供されていないことに注意してください。
このパラメータはpostgresql.conf
ファイルまたはサーバコマンドラインでのみ設定できます。
debug_logical_replication_streaming
(enum
)
#
The allowed values are <literal>buffered</literal> and
<literal>immediate</literal>. The default is <literal>buffered</literal>.
This parameter is intended to be used to test logical decoding and
replication of large transactions. The effect of
<varname>debug_logical_replication_streaming</varname> is different for the
publisher and subscriber:
指定できる値は、buffered
およびimmediate
です。
デフォルトはbuffered
です。
このパラメータは、大きなトランザクションにおけるロジカルデコーディングおよびレプリケーションのテストに使用することを目的としています。
debug_logical_replication_streaming
の効果は、パブリッシャーとサブスクライバーで異なります。
On the publisher side, <varname>debug_logical_replication_streaming</varname>
allows streaming or serializing changes immediately in logical decoding.
When set to <literal>immediate</literal>, stream each change if the
<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>
option of
<link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>
is enabled, otherwise, serialize each change. When set to
<literal>buffered</literal>, the decoding will stream or serialize
changes when <varname>logical_decoding_work_mem</varname> is reached.
パブリッシャー側では、debug_logical_replication_streaming
を使用すると、ロジカルデコーディングでただちに変更をストリーミングまたはシリアル化できます。
immediate
に設定すると、CREATE SUBSCRIPTION
のstreaming
オプションが有効になっている場合は各変更をストリームし、それ以外の場合は各変更をシリアル化します。
buffered
に設定すると、logical_decoding_work_mem
に達したときに、デコーディング処理がストリームまたはシリアル化します。
On the subscriber side, if the <literal>streaming</literal> option is set to
<literal>parallel</literal>, <varname>debug_logical_replication_streaming</varname>
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
<literal>buffered</literal>, the leader sends changes to parallel apply
workers via a shared memory queue. When set to
<literal>immediate</literal>, the leader serializes all changes to files
and notifies the parallel apply workers to read and apply them at the
end of the transaction.
サブスクライバー側では、streaming
オプションがparallel
に設定されている場合、debug_logical_replication_streaming
を使用して、リーダー適用ワーカーに変更を共有メモリキューに送信するか、すべての変更をファイルにシリアル化するように指示できます。
buffered
に設定されている場合、リーダーは共有メモリキューを介してパラレル適用ワーカーに変更を送信します。
immediate
に設定されている場合、リーダーはファイルに対するすべての変更をシリアル化し、パラレル適用ワーカーにファイルを読み取ってトランザクションの最後に適用するように通知します。