log_destination
(string
)
#
PostgreSQLは、stderr、jsonlog、csvlog、jsonlogおよびsyslogを含めて、サーバメッセージのログ出力に対し数種類の方法を提供します。
Windowsでは、eventlogも同時に提供します。
このパラメータを設定するには、カンマ区切りでお好みのログ出力先を記載します。
デフォルトでは、ログはstderrのみに出力されます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
csvlogがlog_destination
に含まれる場合、ログ項目はプログラムへの読み込みが簡便な「カンマ区切り値」書式(CSV)で出力されます。
詳細は19.8.4を参照してください。
CSV書式のログ出力を生成するためにはlogging_collectorを有効にする必要があります。
jsonlogがlog_destination
に含まれる場合、ログ項目はプログラムへの読み込みが簡便なJSON書式で出力されます。
詳細は19.8.5を参照してください。
JSON書式のログ出力を生成するためにはlogging_collectorを有効にする必要があります。
stderr、csvlog、またはjsonlogのいずれかが含まれている場合、ファイルcurrent_logfiles
が作成され、ロギングコレクタによって現在使用されているログファイルの場所と関連付けられたロギング先が記録されます。
これにより、インスタンスによって現在使用されているログを簡単に見つけることができます。
このファイルの内容の例を次に示します:
stderr log/postgresql.log csvlog log/postgresql.csv jsonlog log/postgresql.json
current_logfiles
は、ローテーションの効果として新しいログファイルが作成されたとき、およびlog_destination
がリロードされたときに再作成されます。
stderr、csvlog、jsonlogのいずれもlog_destination
に含まれていないとき、およびロギングコレクタが無効になっているときに削除されます。
log_destination
でsyslogオプションを使用できるようにするために、ほとんどのUnixシステムではシステムのsyslogデーモンの設定を変更しなければならないでしょう。
PostgreSQLではログをLOCAL0
からLOCAL7
までのsyslogファシリティで記録することができます(syslog_facilityを参照してください)。
しかし、ほとんどのプラットフォームのデフォルトのsyslog設定ではこれらのメッセージはすべて破棄されます。
うまく動作させるために
local0.* /var/log/postgresql
syslogデーモンの設定ファイルに追加しなければならないでしょう。
Windowsでlog_destination
に対しeventlog
オプションを使用する場合、Windows Event Viewer がイベントログメッセージを手際良く表示できるよう、オペレーティングシステムでイベントソースとそのライブラリを登録しなければなりません。
詳細は18.12を参照ください。
logging_collector
(boolean
)
#
このパラメータはログ収集機構を有効にします。
それはstderrに送られたログメッセージを捕捉し、ログファイルにリダイレクトするバックグラウンドプロセスです。
この手法はsyslogへのログよりもしばしば有用です。
メッセージの一部の種類がsyslogでは出力されない可能性があるためです。
(一般的な例として、ダイナミックリンカのエラーメッセージがあり、その他の例としてarchive_command
のようなスクリプトにより生成されたエラーメッセージが挙げられます。)
このパラメータはサーバ起動時のみ設定可能です。
ログ収集機構を使用せずにstderrのログを取ることは可能です。 ログメッセージはサーバのstderrが指し示すいかなる場所にも向かうだけです。 しかし、その方法はログファイルを巡回させる都合のよい方法を提供しないので、ログ容量が小さい場合のみに適しています。 同時に、ログ収集機構を使用しないいくつかのプラットフォームにおいては、ログ出力が失われたり、文字化けします。なぜなら、同一のログファイルに同時に書き込みを行うマルチプロセッサはそれぞれの出力を上書きできるからです。
ログ収集機構はメッセージを決して失わないために設計されています。 これは、極端に高い負荷の場合、サーバプロセスはコレクタが遅れをとった場合、追加のログメッセージを送信しようと試みる時に阻止される可能性があります。 それとは対象的にsyslogは、もし書き込みができなかったときメッセージの廃棄を選びます。 これらの場合にはいくつかのログメッセージを失うことになりますが、残ったシステムを阻止しません。
log_directory
(string
)
#
logging_collector
を有効と設定した場合、このパラメータはログファイルが作成されるディレクトリを確定します。
ディレクトリは、絶対パス、もしくはデータベースクラスタのディレクトリに対する相対パスで指定することができます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
デフォルトはlog
です。
log_filename
(string
)
#
logging_collector
が有効な場合、このパラメータは作成されたログファイルのファイル名を設定します。
値はstrftime
パターンとして扱われるため、%
エスケープを使用して、時刻によって変動するファイル名を指定することができます。
(時間帯に依存した%
エスケープが存在する場合、log_timezoneで指定された時間帯で計算が行われます。)
サポートされている%
-エスケープはstrftime 仕様によく似ています。
システムのstrftime
は直接使用されないので、プラットフォーム固有の(非標準)の拡張は動作しません。
デフォルトはpostgresql-%Y-%m-%d_%H%M%S.log
です。
エスケープすることなくファイル名を指定する場合、ディスク全体を使い切ってしまうことを防止するためにログローテーションを行うユーティリティを使用することを計画しなければなりません。
8.4より前のリリースのPostgreSQLでは、%
エスケープがなければ、新しいログファイルの生成時のエポック時刻を付与しますが、これはもはや当てはまりません。
CSV書式の出力がlog_destination
で有効な場合、タイムスタンプ付きのログファイル名に.csv
を付与し、最終的なCSV書式出力用のファイル名が作成されます。
(log_filename
が.log
で終わる場合は後置詞が置き換えられます。)
JSON書式の出力がlog_destination
で有効な場合、タイムスタンプ付きのログファイル名に.json
を付与し、最終的なJSON書式出力用のファイル名が作成されます。
(log_filename
が.log
で終わる場合は後置詞が置き換えられます。)
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_file_mode
(integer
)
#
Unixシステムにおいては、logging_collector
が有効になっている場合、このパラメータはログファイルのパーミッションを設定します。
(Microsoft Windowsではこのパラメータは無視されます。)
パラメータの値はchmod
および umask
システムコールで許容されるフォーマットで指定される数値モードであると期待されます。
(慣例的な8進数フォーマットを使用する場合、番号は0
(ゼロ)で始まらなければなりません。
デフォルトのパーミッションは0600
で、意味するところはサーバの所有者のみログファイルの読み書きが可能です。
そのほか一般的に実用的な設定は0640
で、所有者のグループはファイルを読み込めます。
しかし、これらの設定を活用するにはlog_directoryがクラスタデータディレクトリの外部のどこかにあるファイルを格納できるように変更する必要があります。
いずれにせよ、それらは機密データを含む可能性があるため、ログファイルを誰もが読み取り可能にすることは賢明ではありません。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_rotation_age
(integer
)
#
logging_collector
が有効な場合、このパラメータは個々のログファイルの最大寿命を決定します。
ここで指定した時間経過すると、新しいログファイルが生成されます。
この値が単位なしで指定された場合は、分単位であるとみなします。
デフォルトは24時間です。
ゼロに設定することで、時間に基づいた新しいログファイルの生成は無効になります。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_rotation_size
(integer
)
#
logging_collector
が有効な場合、このパラメータは個々のログファイルの最大容量を決定します。
ここで指定したデータ量がログファイルに出力された後、新しいログファイルが生成されます。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルトは10メガバイトです。
ゼロに設定することで、サイズに基づいた新しいログファイルの生成は無効になります。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_truncate_on_rotation
(boolean
)
#
logging_collector
が有効な場合、このパラメータにより、PostgreSQLは既存の同名のファイルに追加するのではなく、そのファイルを切り詰める(上書きする)ようになります。
しかし、切り詰めは時間を基にしたローテーションのために新規にファイルが開かれた時にのみ発生し、サーバ起動時やサイズを基にしたローテーションでは発生しません。
偽の場合、全ての場合において既存のファイルは追記されます。
例えば、この設定をpostgresql-%H.log
のようなlog_filename
と組み合わせて使用すると、24個の時別のログファイルが生成され、それらは周期的に上書きされることになります。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
例:7日間のログを保存し、毎日のログを server_log.Mon
、server_log.Tue
、等とし、そして自動的に前週のログを今週のログで上書きするには以下のように設定します。
log_filename
を server_log.%a
とし、log_truncate_on_rotation
を on
にし、そしてlog_rotation_age
を 1440
に設定します。
例:24時間のログを保持、1時間おきに1つのログファイルを作成、ただし、ログファイルのサイズが1ギガバイトを超えた場合それより早く切り替えさせるには、log_filename
をserver_log.%H%M
にし、log_truncate_on_rotation
をon
にし、log_rotation_age
を60
にし、そしてlog_rotation_size
を1000000
に設定します。
log_filename
に%M
を含めると、サイズを元にしたローテーションが時間毎の始めのファイル名とは異なる名前のファイルを選択するようにできます。
syslog_facility
(enum
)
#
syslogへのログ出力が有効な場合、このパラメータはsyslogの「facility」が使われるように確定します。
LOCAL0
、LOCAL1
、LOCAL2
、LOCAL3
、LOCAL4
、LOCAL5
、LOCAL6
、LOCAL7
の中から選んでください。
デフォルトはLOCAL0
です。
使用しているシステムのsyslogデーモンの文書を同時に参照してください。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
syslog_ident
(string
)
#
syslogにログ出力が有効な場合、このパラメータはsyslogログ内のPostgreSQLメッセージを特定するのに使用するプログラム名を確定します。デフォルトはpostgres
です。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
syslog_sequence_numbers
(boolean
)
#
syslogにログを出力している場合で、これがオン(デフォルト)であると、各メッセージには([2]
のような)増加する順序数が頭に追加されます。
これにより、多くのsyslogの実装がデフォルトで行う「--- last message repeated N times ---」による出力の抑止が回避されます。
より近代的なsyslogの実装では、繰り返されるメッセージの抑止は設定変更できるので(たとえば、rsyslog)における$RepeatedMsgReduction
)、この機能は必要ないかもしれません。
繰り返されるメッセージを抑止したい場合には、これをオフにできます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
syslog_split_messages
(boolean
)
#syslogへのログ出力が有効な場合、このパラメータはメッセージがどのようにsyslogに送られるかを規定します。 オンなら(デフォルト)、メッセージは行に分割され、長い行は、伝統的なsyslog実装のサイズ上限である1024バイト以内に分割されます。 オフならば、PostgreSQLサーバログメッセージは、そのままsyslogサービスに送られます。 大きなサイズになるかもしれないメッセージにどう対応するかは、syslogサービス次第となります。
もしsyslogが最終的にテキストファイルにログを出力するのであれば、どちらに設定しても効果は同じです。 設定値をオンにしておくのが最善です。 多くのsyslogの実装では、長いメッセージを扱えないか、長いメッセージを扱うための特別な設定が必要だからです。 しかし、syslogが最終的に他のメディアに書き込むのであれば、メッセージを論理的に一緒にしておくことが必要か、もしくは有用です。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
event_source
(string
)
#
event logへのログ出力が有効になっていると、このパラメータはログ中のPostgreSQLメッセージを特定するのに使用されるプログラム名を決定します。デフォルトはPostgreSQL
です。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_min_messages
(enum
)
#
どのメッセージレベルをサーバログに書き込むかを管理します。
有効な値はDEBUG5
、DEBUG4
、DEBUG3
、DEBUG2
、DEBUG1
、INFO
、NOTICE
、WARNING
、ERROR
、LOG
、FATAL
、およびPANIC
です。
それぞれの階層はその下の全ての階層を含みます。階層を低くする程、より少ないメッセージがログに送られます。
デフォルトはWARNING
です。
ここでのLOG
の優先順位がclient_min_messagesの場合と異なることに注意してください。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_min_error_statement
(enum
)
#
エラー条件の原因となったどのSQL文をサーバログに記録するかを制御します。
設定したレベル以上のメッセージについては現在のSQL文がログに記録されます。
有効な値は、DEBUG5
、DEBUG4
、DEBUG3
、DEBUG2
、DEBUG1
、INFO
、NOTICE
、WARNING
、ERROR
、LOG
、FATAL
、PANIC
です。
デフォルトはERROR
です。
エラー、ログメッセージ、致命的エラー、パニックを引き起こした文がログに記録されることを意味します。
失敗した文の記録を実質的に無効にするには、このパラメータをPANIC
に設定してください。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_min_duration_statement
(integer
)
#
文の実行に少なくとも指定した時間かかった場合、それぞれの文の実行に要した時間をログに記録します。
例えば、250ms
と設定した場合、250msもしくはそれ以上長くかかった全てのSQL文がログとして残ります。
このパラメータを有効にすることにより、アプリケーションで最適化されていない問い合わせを追跡するのが便利になります。
この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。
0に設定すれば、すべての文の実行時間が出力されます。
-1
(デフォルト)は、文実行時間の記録を無効にします。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
これはlog_min_duration_sampleを上書きします。つまり、問い合わせがこの設定を越えると、実行時間のサンプリングの対象にならず、常に記録されます。
拡張問い合わせプロトコルを使用するクライアントでは、Parse、Bind、Executeそれぞれの段階で要した時間が独立して記録されます。
このオプションとlog_statementを一緒に使用する時、log_statement
によって記録されるテキスト文は、実行時間のログには重複されません。
syslogを使用していなければ、プロセスIDとセッションIDを使用して、文メッセージと後の実行時間メッセージを関連付けできるように、log_line_prefixを使用してPIDまたはセッションIDをログに記録することを勧めます。
log_min_duration_sample
(integer
)
#
指定した時間以上で実行完了した文の実行時間のサンプルを許可します。
これによりlog_min_duration_statementと同様ですが、log_statement_sample_rateで制御するレートでサンプルされた実行時間のサブセットのログエントリを生成します。
たとえば、100ms
に設定すると、100ミリ秒以上かかったSQL文がサンプルの対象となります。
このパラメータを有効にすることで、トラフィックが多すぎてすべての問い合わせをログできない状況で助けになることもあります。
この値を単位無しで指定すると、ミリ秒と見なされます。
これをゼロに設定すると、すべての文の実行時間がサンプルされます。
-1
(デフォルトです)とすると、文の実行時間のサンプリングが無効になります。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
この設定はlog_min_duration_statement
よりも優先度が低いです。つまり、log_min_duration_statement
を超えた実行時間の文はサンプリングの対象となり、常に記録されます。
log_min_duration_statement
のその他の注意事項もこの設定に適用されます。
log_statement_sample_rate
(floating point
)
#
log_min_duration_sampleを越え、記録対象となる文の割合を決定します。
サンプリングは確率論的で、たとえば0.5
は2つの文のうちひとつが統計的に記録対象になることを意味します。
デフォルトは1.0
で、サンプルされた文はすべて記録対象となります。
ゼロに設定すると、log_min_duration_sample
を-1
にしたのと同じで、文の実行時間のサンプルを記録しません。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_transaction_sample_rate
(floating point
)
#
他の理由に加え、トランザクションの文のうち、ログの対象となる割合を設定します。
文の実行時間にかかわらず、新しいトランザクションに適用されます。
サンプリングは確率論的で、たとえば0.1
は10のトランザクションのうちひとつが統計的に記録対象になることを意味します。
デフォルトは0
で、これは追加のトランザクションのログを取らないことを意味します。
1
に設定すると、すべてのトランザクションのすべての文のログを取ります。
log_transaction_sample_rate
は、トランザクションのサンプルを調査するのに役立ちます。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
他の文のログを取るオプション同様、このオプションも大きなオーバーヘッドを与える可能性があります。
log_startup_progress_interval
(integer
)
#
起動プロセスが実行中の長時間実行操作に関するメッセージをログに記録するまでの時間と、その操作に関する次の進行状況メッセージの間隔を設定します。
デフォルトは10秒です。
0
に設定すると、この機能は無効になります。この値を単位なしで指定すると、ミリ秒とみなされます。
この設定は、各操作に個別に適用されます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
たとえば、データディレクトリの同期に25秒かかり、その後、unloggedリレーションのリセットに8秒かかったとします。 この設定がデフォルト値の10秒である場合、データディレクトリを同期するためのメッセージは、10秒間処理された後と20秒間処理された後に記録されますが、unloggedリレーションのリセットに関しては何も記録されません。
表 19.2で、PostgreSQLで使用されるメッセージ深刻度レベルを説明します。 ログ出力がsyslogまたはWindowsのeventlogに送られる場合、この深刻度レベルは表で示すように変換されます。
表19.2 メッセージ深刻度レベル
深刻度 | 使用方法 | syslog | eventlog |
---|---|---|---|
DEBUG1 .. DEBUG5 | 開発者が使用する連続的かつより詳細な情報を提供します。 | DEBUG | INFORMATION |
INFO | VACUUM VERBOSE の出力などの、ユーザによって暗黙的に要求された情報を提供します。 | INFO | INFORMATION |
NOTICE | 長い識別子の切り詰めに関する注意など、ユーザの補助になる情報を提供します。 | NOTICE | INFORMATION |
WARNING | トランザクションブロック外でのCOMMIT の様な、ユーザへの警告を提供します。 | NOTICE | WARNING |
ERROR | 現在のコマンドを中断させる原因となったエラーを報告します。 | WARNING | ERROR |
LOG | チェックポイントの活動の様な、管理者に関心のある情報を報告します。 | INFO | INFORMATION |
FATAL | 現在のセッションを中断させる原因となったエラーを報告します。 | ERR | ERROR |
PANIC | 全てのデータベースセッションを中断させる原因となったエラーを報告します。 | CRIT | ERROR |
ログに出力する内容は、セキュリティに影響を与える可能性があります。 24.3を参照してください。
application_name
(string
)
#
application_name
はNAMEDATALEN
文字未満の任意の文字列(標準ビルドでは64文字)にすることができます。
これは通常、サーバへの接続時にアプリケーションによって設定されます。
この名前はpg_stat_activity
ビューに表示され、CSVログエントリに含まれます。
またlog_line_prefixパラメータにより通常のログ項目に含めることができます。
application_name
値には印字可能なASCII文字のみを使用できます。
他の文字はCスタイルの16進エスケープ文字に置き換えられます。
debug_print_parse
(boolean
)
debug_print_rewritten
(boolean
)
debug_print_plan
(boolean
)
#
これらのパラメータは生成される各種デバッグ出力を有効にします。
設定すると実行された問い合わせそれぞれに対し、最終的な解析ツリー、問い合わせリライタの出力、実行計画を出力します。
これらのメッセージはLOG
メッセージレベルで出力されますので、デフォルトではサーバログに出力され、クライアントには渡されません。
client_min_messages、log_min_messagesまたはその両方を調整することで変更することができます。
デフォルトではこれらのパラメータは無効です。
debug_pretty_print
(boolean
)
#
設定された場合、debug_pretty_print
はdebug_print_parse
、debug_print_rewritten
、またはdebug_print_plan
で生成されたメッセージを字下げします。
設定されない場合の「コンパクト」形式よりもより見やすく、しかしより長いものとなります。デフォルトは有効です。
log_autovacuum_min_duration
(integer
)
#
少なくとも指定時間実行した場合、autovacuumで実行される各活動がログに残るようになります。
これをゼロに設定すると、すべてのautovacuumの活動がログに残ります。
-1
はautovacuum活動のログを無効にします。
この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。
例えば、これを250ms
に設定すると、250ms以上かかって実行されたautovacuumやanalyzeはすべてログに残ります。
さらに、-1
以外の値にこのパラメータが設定された場合、競合するロックや並行して削除されたリレーションによりautovacuum動作がスキップされるとメッセージはログに記録されます。
デフォルトは10min
です。
このパラメータを有効にすることは、autovacuum活動の追跡に役に立ちます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
ただし、この設定はテーブルストレージパラメータの変更により、それぞれのテーブルに対して上書きすることができます。
log_checkpoints
(boolean
)
#
チェックポイントおよびリスタートポイントをサーバログに記録するようにします。
書き出されたバッファ数や書き出しに要した時間など、いくつかの統計情報がこのログメッセージに含まれます。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
デフォルトはonです。
log_connections
(boolean
)
#
サーバへの接続試行とともに、クライアント認証の成功終了と(必要ならば)承認をログに残します。
スーパーユーザと、適切なSET
権限を持つユーザだけがセッション開始時にこのパラメータを変更でき、セッションが開始された後は変更できません。
デフォルトはoff
です。
psqlなどクライアントプログラムは、パスワードが要求されているかどうか確認するまで2回接続を試みるので、二重の「connection received」メッセージは必ずしも問題を示すものではありません。
log_disconnections
(boolean
)
#
セッションの終了をログします。
ログ出力の情報はlog_connections
と同様で、更にセッションの経過時間が追加されます。
スーパーユーザと、適切なSET
権限を持つユーザだけがセッション開始時にこのパラメータを変更でき、セッションが開始された後は変更できません。
デフォルトはoff
です。
log_duration
(boolean
)
#
すべての完了した文について、その経過時間をログするようにします。
デフォルトはoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
拡張問い合わせプロトコルを使用するクライアントでは、Parse、Bind、Executeそれぞれの段階で要した時間が独立して記録されます。
log_duration
を有効にするのとlog_min_duration_statementを0に設定する方法との違いは、log_min_duration_statement
を超えた場合、テキスト版の問い合わせが強制的に出力されるのに対して、このオプションでは出力されないという点です。
したがって、log_duration
がon
、かつ、log_min_duration_statement
が正の値を持つ場合、すべての経過時間がログに記録されますが、閾値を超えた文のみがテキスト版の問い合わせが含められるようになります。
この動作は、高負荷なインストレーションで統計情報を収集する際に有用です。
log_error_verbosity
(enum
)
#
ログ出力されるそれぞれのメッセージに対し、サーバログに書き込まれる詳細の量を制御します。
有効な値は、TERSE
、DEFAULT
、およびVERBOSE
で、それぞれは表示されるメッセージにより多くのフィールドを追加します。
TERSE
はDETAIL
、HINT
、QUERY
、およびCONTEXT
エラー情報を除外します。
VERBOSE
出力は、SQLSTATE
エラーコード(付録Aも参照)、および、ソースコードファイル名、関数名、そしてエラーを生成した行番号を含みます。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_hostname
(boolean
)
#
デフォルトでは、接続ログメッセージは接続元ホストのIPアドレスのみを表示します。
このパラメータを有効にすると、ホスト名もログに残るようになります。
ホスト名解決方法の設定に依存しますが、これが無視できないほどの性能劣化を起こす可能性があることに注意してください。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_line_prefix
(string
)
#
これは、各ログ行の先頭に出力するprintf
の書式文字列です。
%
から始まる「エスケープシーケンス」は、後述の通りのステータス情報で置き換えられます。
この他のエスケープは無視されます。
他の文字はそのままログ行に出力されます。
エスケープの中には、セッションプロセスによってのみ認識可能なものがあり、これらはメインサーバプロセスなどのバックグラウンドプロセスでは空文字として扱われます。
状態情報は%の後かつオプションの前に数字を指定することにより、左寄せまた右寄せにすることができます。
数字が負ならば状態情報を右側に空白を詰めて最小限の幅にし、正の値は左に空白を詰めます。
ログファイルではパディングは人間の視認性を向上させるので有用です。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
デフォルトは、タイムスタンプとプロセスIDをログ出力する'%m [%p] '
です。
エスケープ | 効果 | セッションのみ |
---|---|---|
%a | アプリケーション名 | ○ |
%u | ユーザ名 | ○ |
%d | データベース名 | ○ |
%r | 遠隔ホスト名、またはIPアドレス、およびポート番号 | ○ |
%h | 遠隔ホスト名、またはIPアドレス | ○ |
%b | バックエンドタイプ | × |
%p | プロセス識別子 | × |
%P | このプロセスがパラレルクエリワーカーである場合に、パラレルグループリーダーのプロセス識別子 | × |
%t | ミリ秒無しのタイムスタンプ | × |
%m | ミリ秒付きタイムスタンプ | × |
%n | ミリ秒付きタイムスタンプ(Unixエポックとして) | × |
%i | コマンドタグ。セッションの現在のコマンド種類 | ○ |
%e | SQLSTATE エラーコード | × |
%c | セッションID。下記参照 | × |
%l | 各セッションまたは各プロセスのログ行の番号。1から始まります。 | × |
%s | プロセスの開始タイムスタンプ | × |
%v | 仮想トランザクションID(procNumber/localXID)。 66.1を参照してください | × |
%x | トランザクションID(何もアサインされていない場合0)。 66.1参照 | × |
%q | 何も出力しません。 非セッションプロセスではこのエスケープ以降の出力を停止します。 セッションプロセスでは無視されます。 | × |
%Q | 現在の問い合わせの問い合わせ識別子。問い合わせ識別子はデフォルトでは計算されません。 ですからcompute_query_idパラメータが有効であるか、あるいは問い合わせ識別子を計算するサードパーティのモジュールが設定されていないければゼロとなります。 | ○ |
%% | % 文字そのもの | × |
バックエンドタイプはpg_stat_activity
ビューのbackend_type
に関連します。しかし、ビューにない他のタイプがログに現れることがあります。
%c
エスケープは、2つの4バイトの16進数(先頭のゼロは省略)をドットで区切った構成の、準一意なセッション識別子を表示します。
この数値はプロセスの起動時間とそのプロセスIDです。
したがって、%c
を使用して、これらの項目を出力するための文字数を省略することができます。例として、pg_stat_activity
からセッション識別子を生成するには以下の問い合わせを行ないます。
SELECT to_hex(trunc(EXTRACT(EPOCH FROM backend_start))::integer) || '.' || to_hex(pid) FROM pg_stat_activity;
log_line_prefix
に空白文字以外の値を設定する場合、通常、ログ行の残りとの区切りを明確にするために、その最後の文字を空白文字にすべきです。
句読点用の文字も使用できます。
Syslogは独自にタイムスタンプとプロセスID情報を生成します。 ですのでおそらく、Syslogにログを保管する場合は、こうしたエスケープを含めるとは考えないでしょう。
%q
エスケープは、ユーザやデータベース名のように、セッション(バックエンド)コンテキストでのみ存在する情報を含める場合に有用です。
%q
log_line_prefix = '%m [%p] %q%u@%d/%a '
識別子が計算できない不正な文も含め、log_statement
は識別子が計算可能になる前に出力を生成するため、%Q
エスケープは、log_statementが生成する行では常にゼロの識別子を報告します。
log_lock_waits
(boolean
)
#
セッションがロックの獲得までの間にdeadlock_timeoutより長く待機する場合にログメッセージを生成するかどうかを制御します。
これは、ロック待ちによって性能がでていないのかどうか確認する時に有用です。
デフォルトはoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_recovery_conflict_waits
(boolean
)
#
スタートアッププロセスがdeadlock_timeout
よりも長くリカバリコンフリクトを待つ場合にログメッセージを出力するかどうかを制御します。
リカバリコンフリクトによってリカバリがWALを適用するのを妨げられているかどうかを決定するのに有用です。
デフォルトはoff
です。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_parameter_max_length
(integer
)
#
ゼロよりも大きければ、エラーではない時にバインドパラメータ値が、文とともにこの指定バイト数に短縮されて記録されます。
ゼロなら、エラーではない時のバインドパラメータ値と文の記録は行われません。
-1
(デフォルトです)ならバインドパラメータはすべて記録されます。
この値が単位なしに指定されると、バイト単位と見なされます。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
この設定は、log_statement、log_durationおよび関連設定の結果を表示するログメッセージにのみ影響します。 ゼロ以外の値の設定は、とりわけパラメータがバイナリ形式で送信される際に多少のオーバーヘッドをもたらします。 テキストへの変換が必要になるからです。
log_parameter_max_length_on_error
(integer
)
#
ゼロよりも大きければ、エラー時のバインドパラメータ値が、エラーメッセージ中にこの指定バイト数に短縮されて記録されます。
ゼロ(デフォルトです)ならエラーメッセージ中のバインドパラメータは記録されません。
-1
ならバインドパラメータはすべて記録されます。
この値が単位なしに指定されると、バイト単位と見なされます。
ゼロ以外の値の設定は多少のオーバーヘッドをもたらします。 エラーが起きるかどうかに関わらず、PostgreSQLは文を開始する際にテキスト形式のパラメータ値をメモリに保存する必要があるからです。 パラメータがバイナリ形式で送信される場合にテキスト形式で送信するよりもオーバーヘッドが大きくなります。 前者はデータ変換が必要なのに対し、後者は単に文字列をコピーするだけだからです。
log_statement
(enum
)
#
どのSQL文をログに記録するかを制御します。
有効な値は、none
(off)、ddl
、mod
、およびall
(全ての文)です。
ddl
は、CREATE
、ALTER
、およびDROP
文といった、データ定義文を全てログに記録します。
mod
は、全てのddl
文に加え、INSERT
、UPDATE
、DELETE
、TRUNCATE
、およびCOPY FROM
といった、データ変更文をログに記録します。
PREPARE
、EXECUTE
およびEXPLAIN ANALYZE
コマンドも、そこに含まれるコマンドが適切な種類であればログが録られます。
拡張問い合わせプロトコルを使用するクライアントでは、Executeメッセージを受け取った時にBindパラメータの値が(すべての単一引用符が二重にされた状態で)含まれていた場合、ログに記録されます。
デフォルトはnone
です。
スーパーユーザおよび適切なSET
権限を持つユーザのみがこの設定を変更できます。
ログメッセージの発行は、基本解析により文の種類が決まった後に行われますので、log_statement
= all
という設定を行ったとしても、単純な構文エラーを持つ文は記録されません。
拡張問い合わせプロトコルの場合も同様に、この設定ではExecute段階以前(つまり、解析や計画作成期間)に失敗した文は記録されません。
こうした文のログを記録するには、log_min_error_statement
をERROR
(以下)に設定してください。
ログに記録された文は、機密データを明らかにし、プレーンテキストのパスワードを含むことさえあります。
log_replication_commands
(boolean
)
#
サーバログに各レプリケーションコマンドと、walsender
プロセスのレプリケーションスロットの獲得/解放を記録します。
レプリケーションコマンドの更なる情報は53.4をご覧ください。
デフォルト値はoff
です。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。
log_temp_files
(integer
)
#
一時ファイルのファイル名とサイズのログ出力を制御します。
一時ファイルはソート処理やハッシュ処理、一時的な問い合わせの結果のために作成されます。
この設定が有効になると、指定されたファイルのバイト単位の大きさを伴うログの項目が、すべての一時ファイルそれぞれについて削除されたときに生成されます。
0を指定すると、すべての一時ファイル情報のログが残ります。
正の数を指定すると、指定した以上の容量のファイルのみがログに残ります。
この値が単位なしで指定された場合は、キロバイト単位であるとみなします。
デフォルトの設定は-1で、このログ出力を無効にします。
スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。
この設定を変更できるのは、スーパーユーザと適切なSET
権限を持つユーザだけです。
log_timezone
(string
)
#
サーバログに書き出す際に使用される時間帯を設定します。
TimeZoneと異なり、すべてのセッションで一貫性を持ってタイムスタンプが報告されるようにこの値はクラスタ全体に適用されます。
組み込まれているデフォルトはGMT
ですが、postgresql.conf
により通常は上書きされます。initdbによりこれらと関連した設定をシステム環境にインストールされます。
詳細は8.5.3を参照してください。
このパラメータは、postgresql.conf
ファイルか、サーバのコマンドラインでのみ設定可能です。
log_destination
リストにcsvlog
を含めることは、ログファイルをデータベーステーブルにインポートする簡便な方法を提供します。このオプションはカンマ区切り値書式(CSV)で以下の列を含むログ行を生成します。
ミリ秒単位のtimestamp、
ユーザ名、
データベース名、
プロセスID、
クライアントホスト:ポート番号、
セッションID、
セッション前行番号、
コマンドタグ、
セッション開始時間、
仮想トランザクションID、
通常トランザクションID、
エラーの深刻度、
SQLSTATEコード、
エラーメッセージ、
詳細エラーメッセージ、
ヒント、
エラーとなった内部的な問い合わせ(もしあれば)、
内部問い合わせにおけるエラー位置の文字数、
エラーの文脈、
エラーの原因となったユーザ問い合わせ(存在しlog_min_error_statement
で有効になっている場合)、
エラー位置の文字数、
PostgreSQLソースコード上のエラー発生場所(log_error_verbosity
がverbose
に設定されているならば)、
アプリケーション名、バックエンドタイプ、パラレルグループリーダーのプロセスID、問い合わせID。
以下にcsvlog出力を格納するためのテーブル定義のサンプルを示します。
CREATE TABLE postgres_log ( log_time timestamp(3) with time zone, user_name text, database_name text, process_id integer, connection_from text, session_id text, session_line_num bigint, command_tag text, session_start_time timestamp with time zone, virtual_transaction_id text, transaction_id bigint, error_severity text, sql_state_code text, message text, detail text, hint text, internal_query text, internal_query_pos integer, context text, query text, query_pos integer, location text, application_name text, backend_type text, leader_pid integer, query_id bigint, PRIMARY KEY (session_id, session_line_num) );
このテーブルにログファイルをインポートするためには、COPY FROM
コマンドを使用してください。
COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv;
提供されたfile_fdwモジュールを使って外部テーブルとしてファイルをアクセスすることも可能です。
CSVログファイルをインポートする作業を単純にするためにいくつか必要な作業があります。
一貫性があり、予測可能なログファイル命名機構を提供するために、log_filename
およびlog_rotation_age
を設定してください。
これによりどのようなファイル名になると、個々のログファイルが完了しインポートする準備が整ったかが推測できるようになります。
ログファイル名の予測が困難になりますので、log_rotation_size
を0にして容量を基にしたログの回転を無効にしてください。
同じファイルに古いログデータと新しいログデータが混在しないようにするために、log_truncate_on_rotation
をon
に設定してください。
上のテーブル定義には主キーの指定が含まれています。
これにより、同じ情報が2回インポートされる事故を防止するために有用です。
COPY
コマンドは、一度にインポートするすべてのデータをコミットしますので、何か1つでもエラーがあればインポート全体が失敗します。
ログファイルの一部をインポートし、そのファイルが完了した後に再度インポートしようとした場合、主キー違反によりインポートが失敗します。
インポートする前に、ログファイルの完了を待ち、閉じるまで待機してください。
この手順は、COPY
が失敗する原因となる、完全に書き込まれなかった欠落した行をインポートするという事故も防止します。
log_destination
リストにjsonlog
を含めると、ログファイルをさまざまなプログラムにインポートするのに便利です。
このオプションは、JSON書式のログ行を出力します。
NULL値を持つ文字列フィールドは出力から除外されます。
将来、フィールドが追加される可能性があります。
jsonlog
出力を処理するユーザアプリケーションは不明なフィールドを無視する必要があります。
各ログ行はJSONオブジェクトとしてシリアライズされ、一連のキーとそれに関連する値が表 19.3で示されます。
表19.3 JSONログ項目のキーと値
キー名 | 型 | 説明 |
---|---|---|
timestamp | string | ミリ秒単位のタイムスタンプ |
user | string | ユーザ名 |
dbname | string | データベース名 |
pid | number | プロセスID |
remote_host | string | クライアントホスト |
remote_port | number | クライアントポート |
session_id | string | セッションID |
line_num | number | セッション単位の行番号 |
ps | string | 現在のps表示 |
session_start | string | セッション開始時刻 |
vxid | string | 仮想トランザクションID |
txid | string | 通常トランザクションID |
error_severity | string | エラー深刻度 |
state_code | string | SQLSTATEコード |
message | string | エラーメッセージ |
detail | string | エラーメッセージ詳細 |
hint | string | エラーメッセージヒント |
internal_query | string | このエラーの原因となった内部問い合わせ |
internal_position | number | 内部問い合わせへのカーソルインデックス |
context | string | エラーコンテキスト |
statement | string | クライアント提供の問い合わせ文字列 |
cursor_position | number | 問い合わせ文字列へのカーソルインデックス |
func_name | string | エラー位置関数名 |
file_name | string | エラー位置のファイル名 |
file_line_num | number | エラー位置のファイル行番号 |
application_name | string | クライアントアプリケーション名 |
backend_type | string | バックエンドの種類 |
leader_pid | number | 活動中のパラレルワーカーのリーダーのプロセスID |
query_id | number | 問い合わせ識別子 |
これらの設定項目は、サーバプロセスのタイトルを変更します。 プロセスのタイトルは、典型的にはps、あるいはWindowsにおいてはProcess Explorerで見ることができます。 詳細については、27.1を参照してください。
cluster_name
(string
)
#様々な目的のために、このデータベースクラスタ(インスタンス)を識別する名前を設定します。 クラスタ名はこのクラスタのすべてのサーバプロセスのプロセスタイトルに表れます。 更に、スタンバイ接続のデフォルトのアプリケーション名となります。 (synchronous_standby_names参照。)
名前はNAMEDATALEN
文字(標準のビルドでは64文字)より少ない文字列です。
表示可能なASCII文字だけがcluster_name
の値として設定できます。
他の文字は、Cスタイルの16進エスケープ文字に置き換えられます。
空文字''
(これがデフォルト値です)が設定されると、クラスタ名は表示されません。
このパラメータはサーバ起動時にのみ設定できます。
update_process_title
(boolean
)
#
サーバが新しいSQLコマンドを受け取る時に毎回、プロセスタイトルを更新できるようにします。
この設定値はたいていのプラットフォームでon
がデフォルトになっていますが、Windowsではプロセスタイトルを更新するオーバーヘッドが大きいため、off
がデフォルトになっています。
スーパーユーザと、適切なSET
権限を持つユーザのみがこの設定を変更することができます。