他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

20.8. エラー報告とログ取得

20.8.1. ログの出力先

log_destination (string)

PostgreSQLは、stderrjsonlogcsvlogjsonlogおよびsyslogを含めて、サーバメッセージのログ取得に対し数種類の方法を提供します。 Windowsでは、eventlogも同時に提供します。 このパラメータを設定するには、コンマ区切りでお好みのログ出力先を記載します。 デフォルトでは、ログはstderrのみに出力されます。 このパラメータは、postgresql.confファイル、または、サーバのコマンドラインでのみで設定されます。

csvloglog_destinationに含まれる場合、ログ項目はプログラムへの読み込みが簡便なカンマ区切り値書式(CSV)で出力されます。 詳細は20.8.4を参照してください。 CSV書式のログ出力を生成するためにはlogging_collectorを有効にする必要があります。

jsonloglog_destinationに含まれる場合、ログ項目はプログラムへの読み込みが簡便なJSON書式で出力されます。 詳細は20.8.5を参照してください。 JSON書式のログ出力を生成するためにはlogging_collectorを有効にする必要があります。

stderrcsvlog、またはjsonlogのいずれかが含まれている場合、ファイルcurrent_logfilesが作成され、ロギングコレクタによって現在使用されているログファイルの場所と関連付けられたロギング先が記録されます。 これにより、インスタンスによって現在使用されているログを簡単に見つけることができます。 このファイルの内容の例を次に示します:

stderr log/postgresql.log
csvlog log/postgresql.csv
jsonlog log/postgresql.json

current_logfilesは、ローテーションの効果として新しいログファイルが作成されたとき、およびlog_destinationがリロードされたときに再作成されます。 stderrcsvlogjsonlogのいずれもlog_destinationに含まれていないとき、およびロギングコレクタが無効になっているときに削除されます。

注記

log_destinationsyslogオプションを使用できるようにするために、ほとんどのUnixシステムではシステムのsyslogデーモンの設定を変更しなければならないでしょう。 PostgreSQLではログをLOCAL0からLOCAL7までのsyslogファシリティで記録することができます(syslog_facilityを参照してください)。 しかし、ほとんどのプラットフォームのデフォルトのsyslog設定ではこれらのメッセージはすべて破棄されます。 うまく動作させるために

local0.*    /var/log/postgresql

syslogデーモンの設定に追加しなければならないでしょう。

Windowsでlog_destinationに対しeventlogオプションを使用する場合、Windows Event Viewer がイベントログメッセージを手際良く表示できるよう、オペレーティングシステムでイベントソースとそのライブラリを登録しなければなりません。 詳細は19.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.Monserver_log.Tue、等とし、そして自動的に前週のログを今週のログで上書きするには以下のように設定します。 log_filenameserver_log.%aとし、log_truncate_on_rotationonにし、そしてlog_rotation_age1440に設定します。

例:24時間のログを保持、1時間おきに1つのログファイルを作成、ただし、ログファイルのサイズが1ギガバイトを超えた場合それより早く切り替えさせるには、log_filenameserver_log.%H%Mにし、log_truncate_on_rotationonにし、log_rotation_age60にし、そしてlog_rotation_size1000000に設定します。 log_filename%Mを含めると、サイズを元にしたローテーションが時間毎の始めのファイル名とは異なる名前のファイルを選択するようにできます。

syslog_facility (enum)

syslogへのログ取得が有効な場合、このパラメータはsyslogfacilityが使われるように確定します。 LOCAL0LOCAL1LOCAL2LOCAL3LOCAL4LOCAL5LOCAL6LOCAL7の中から選んでください。 デフォルトは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ファイル、または、サーバのコマンドラインでのみで設定されます。

20.8.2. いつログを取得するか

log_min_messages (enum)

どのメッセージレベルをサーバログに書き込むかを管理します。 有効な値はDEBUG5DEBUG4DEBUG3DEBUG2DEBUG1INFONOTICEWARNINGERRORLOGFATAL、およびPANICです。 それぞれの階層はその下の全ての階層を含みます。階層を低くする程、より少ないメッセージがログに送られます。 デフォルトはWARNINGです。 ここでのLOGの優先順位がclient_min_messagesの場合と異なることに注意してください。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

log_min_error_statement (enum)

エラー条件の原因となったどのSQL文をサーバログに記録するかを制御します。 設定したレベル以上のメッセージについては現在のSQL文がログに記録されます。 有効な値は、DEBUG5DEBUG4DEBUG3DEBUG2DEBUG1INFONOTICEWARNINGERRORLOGFATALPANICです。 デフォルトは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リレーションのリセットに関しては何も記録されません。

表 20.2で、PostgreSQLで使用されるメッセージ深刻度レベルを説明します。 ログ出力がsyslogまたはWindowsのeventlogに送られる場合、この深刻度レベルは表で示すように変換されます。

表20.2 メッセージ深刻度レベル

深刻度使用方法syslogeventlog
DEBUG1 .. DEBUG5開発者が使用する連続的かつより詳細な情報を提供します。DEBUGINFORMATION
INFOVACUUM VERBOSEの出力などの、ユーザによって暗黙的に要求された情報を提供します。INFOINFORMATION
NOTICE長い識別子の切り詰めに関する注意など、ユーザの補助になる情報を提供します。NOTICEINFORMATION
WARNINGトランザクションブロック外でのCOMMITの様な、ユーザへの警告を提供します。NOTICEWARNING
ERROR現在のコマンドを中断させる原因となったエラーを報告します。WARNINGERROR
LOGチェックポイントの活動の様な、管理者に関心のある情報を報告します。INFOINFORMATION
FATAL現在のセッションを中断させる原因となったエラーを報告します。ERRERROR
PANIC全てのデータベースセッションを中断させる原因となったエラーを報告します。CRITERROR

20.8.3. 何をログに

注記

ログに記録する内容は、セキュリティに影響を与える可能性があります。 25.3を参照してください。

application_name (string)

application_nameNAMEDATALEN(標準構築では64)文字以下の任意の文字列を指定できます。 通常はサーバへの接続時にアプリケーションによって設定されます。 この名前は pg_stat_activityビューに表示され、CSVログに含まれます。 またlog_line_prefixパラメータにより通常のログ項目に含めることができます。 application_nameには表示可能なASCII文字のみ使用することができ、それ以外の文字は疑問符(?)に置換されます。

debug_print_parse (boolean)
debug_print_rewritten (boolean)
debug_print_plan (boolean)

これらのパラメータは生成される各種デバッグ出力を有効にします。 設定すると実行された問い合わせそれぞれに対し、最終的な解析ツリー、問い合わせリライタの出力、実行計画を出力します。 これらのメッセージはLOGメッセージレベルで出力されますので、デフォルトではサーバログに出力され、クライアントには渡されません。 client_min_messageslog_min_messagesまたはその両方を調整することで変更することができます。 デフォルトではこれらのパラメータは無効です。

debug_pretty_print (boolean)

設定された場合、debug_pretty_printdebug_print_parsedebug_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_durationon、かつ、log_min_duration_statementが正の値を持つ場合、すべての経過時間がログに記録されますが、閾値を超えた文のみがテキスト版の問い合わせが含められるようになります。 この動作は、高負荷なインストレーションで統計情報を収集する際に有用です。

log_error_verbosity (enum)

ログ取得されるそれぞれのメッセージに対し、サーバログに書き込まれる詳細の量を制御します。 有効な値は、TERSEDEFAULT、およびVERBOSEで、それぞれは表示されるメッセージにより多くのフィールドを追加します。 TERSEDETAILHINTQUERY、および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コマンドタグ。セッションの現在のコマンド種類
%eSQLSTATE エラーコード×
%cセッションID。下記参照×
%l各セッションまたは各プロセスのログ行の番号。1から始まります。×
%sプロセスの開始タイムスタンプ×
%v仮想トランザクションID(backendID/localXID)×
%xトランザクションID (未割り当ての場合は0)×
%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_statementlog_durationおよび関連設定の結果を表示するログメッセージにのみ影響します。 ゼロ以外の値の設定は、とりわけパラメータがバイナリ形式で送信される際に多少のオーバーヘッドをもたらします。 テキストへの変換が必要になるからです。

log_parameter_max_length_on_error (integer)

ゼロよりも大きければ、エラー時のバインドパラメータ値が、エラーメッセージ中にこの指定バイト数に短縮されて記録されます。 ゼロ(デフォルトです)ならエラーメッセージ中のバインドパラメータは記録されません。 -1ならバインドパラメータはすべて記録されます。 この値が単位なしに指定されると、バイト単位と見なされます。

ゼロ以外の値の設定は多少のオーバーヘッドをもたらします。 エラーが起きるかどうかに関わらず、PostgreSQLは文を開始する際にテキスト形式のパラメータ値をメモリに保存する必要があるからです。 パラメータがバイナリ形式で送信される場合にテキスト形式で送信するよりもオーバーヘッドが大きくなります。 前者はデータ変換が必要なのに対し、後者は単に文字列をコピーするだけだからです。

log_statement (enum)

どのSQL文をログに記録するかを制御します。 有効な値は、none(off)、ddlmod、およびall(全てのメッセージ)です。 ddlは、CREATEALTER、およびDROP文といった、データ定義文を全てログに記録します。 modは、全てのddl文に加え、INSERTUPDATEDELETETRUNCATE、およびCOPY FROMといった、データ変更文をログに記録します。 PREPAREEXECUTEおよびEXPLAIN ANALYZEコマンドも、そこに含まれるコマンドが適切な種類であればログが録られます。 拡張問い合わせプロトコルを使用するクライアントでは、Executeメッセージを受け取った時にBindパラメータの値が(すべての単一引用符が二重にされた状態で)含まれていた場合、ログに記録されます。

デフォルトはnoneです。 スーパーユーザーおよび適切なSET権限を持つユーザーのみがこの設定を変更できます。

注記

ログメッセージの発行は、基本解析により文の種類が決まった後に行われますので、log_statement = allという設定を行ったとしても、単純な構文エラーを持つ文は記録されません。 拡張問い合わせプロトコルの場合も同様に、この設定ではExecute段階以前(つまり、解析や計画作成期間)に失敗した文は記録されません。 こうした文のログを記録するには、log_min_error_statementERROR(以下)に設定してください。

ログに記録された文は、機密データを明らかにし、プレーンテキストのパスワードを含むことさえあります。

log_replication_commands (boolean)

サーバログにレプリケーションコマンドを記録します。 レプリケーションコマンドの更なる情報は55.4をご覧ください。 デフォルト値はoffです。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

log_temp_files (integer)

一時ファイルのファイル名とサイズのログ出力を制御します。 一時ファイルはソート処理やハッシュ処理、一時的な問い合わせの結果のために作成されます。 有効にすると、ログの項目はすべての一時ファイルそれぞれについて削除されたときに生成されます。 0を指定すると、すべての一時ファイル情報のログが残ります。 正の数を指定すると、指定した以上の容量のファイルのみがログに残ります。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルトの設定は-1で、このログ出力を無効にします。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

log_timezone (string)

サーバログに書き出す際に使用される時間帯を設定します。 TimeZoneと異なり、すべてのセッションで一貫性を持ってタイムスタンプが報告されるようにこの値はクラスタ全体に適用されます。 組み込まれているデフォルトはGMTですが、postgresql.confにより通常は上書きされます。initdbによりこれらと関連した設定をシステム環境にインストールされます。 詳細は8.5.3を参照してください。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

20.8.4. CSV書式のログ出力の利用

log_destinationリストにcsvlogを含めることは、ログファイルをデータベーステーブルにインポートする簡便な方法を提供します。このオプションはカンマ区切り値書式(CSV)で以下の列を含むログ行を生成します。 ミリ秒単位のtimestamp、 ユーザ名、 データベース名、 プロセスID、 クライアントホスト:ポート番号、 セッションID、 セッション前行番号、 コマンドタグ、 セッション開始時間、 仮想トランザクションID、 通常トランザクションID、 エラーの深刻度、 SQLSTATEコード、 エラーメッセージ、 詳細エラーメッセージ、 ヒント、 エラーとなった内部的な問い合わせ(もしあれば)、 内部問い合わせにおけるエラー位置の文字数、 エラーの文脈、 エラーの原因となったユーザ問い合わせ(存在しlog_min_error_statementで有効になっている場合)、 エラー位置の文字数、 PostgreSQLソースコード上のエラー発生場所(log_error_verbosityverboseに設定されているならば)、 アプリケーション名、バックエンドタイプ、パラレルグループリーダーのプロセス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ログファイルをインポートする作業を単純にするためにいくつか必要な作業があります。

  1. 一貫性があり、予測可能なログファイル命名機構を提供するために、log_filenameおよびlog_rotation_ageを設定してください。 これによりどのようなファイル名になると、個々のログファイルが完了しインポートする準備が整ったかが推測できるようになります。

  2. ログファイル名の予測が困難になりますので、log_rotation_sizeを0にして容量を基にしたログの回転を無効にしてください。

  3. 同じファイルに古いログデータと新しいログデータが混在しないようにするために、log_truncate_on_rotationonに設定してください。

  4. 上のテーブル定義には主キーの指定が含まれています。 これにより、同じ情報が2回インポートされる事故を防止するために有用です。 COPYコマンドは、一度にインポートするすべてのデータをコミットしますので、何か1つでもエラーがあればインポート全体が失敗します。 ログファイルの一部をインポートし、そのファイルが完了した後に再度インポートしようとした場合、主キー違反によりインポートが失敗します。 インポートする前に、ログファイルの完了を待ち、閉じるまで待機してください。 この手順は、COPYが失敗する原因となる、完全に書き込まれなかった欠落した行をインポートするという事故も防止します。

20.8.5. JSON書式のログ出力

log_destinationリストにjsonlogを含めると、ログファイルをさまざまなプログラムにインポートするのに便利です。 このオプションは、JSON書式のログ行を出力します。

NULL値を持つ文字列フィールドは出力から除外されます。 将来、フィールドが追加される可能性があります。 jsonlog出力を処理するユーザーアプリケーションは不明なフィールドを無視する必要があります。

各ログ行はJSONオブジェクトとしてシリアライズされ、一連のキーとそれに関連する値が表 20.3で示されます。

表20.3 JSONログ項目のキーと値

キー名説明
timestampstringミリ秒単位のタイムスタンプ
userstringユーザ名
dbnamestringデータベース名
pidnumberプロセスID
remote_hoststringクライアントホスト
remote_portnumberクライアントポート
session_idstringセッションID
line_numnumberセッション単位の行番号
psstring現在のps表示
session_startstringセッション開始時刻
vxidstring仮想トランザクションID
txidstring通常トランザクションID
error_severitystringエラー深刻度
state_codestringSQLSTATEコード
messagestringエラーメッセージ
detailstringエラーメッセージ詳細
hintstringエラーメッセージヒント
internal_querystringこのエラーの原因となった内部問い合わせ
internal_positionnumber内部問い合わせへのカーソルインデックス
contextstringエラーコンテキスト
statementstringクライアント提供の問い合わせ文字列
cursor_positionnumber問い合わせ文字列へのカーソルインデックス
func_namestringエラー位置関数名
file_namestringエラー位置のファイル名
file_line_numnumberエラー位置のファイル行番号
application_namestringクライアントアプリケーション名
backend_typestringバックエンドの種類
leader_pidnumber活動中のパラレルワーカーのリーダーのプロセスID
query_idnumber問い合わせ識別子

20.8.6. プロセスの表題

これらの設定項目は、サーバプロセスの表題を変更します。 プロセスの表題は、典型的にはps、あるいはWindowsにおいてはProcess Explorerで見ることができます。 詳細については、28.1を参照してください。

cluster_name (string)

様々な目的のために、このデータベースクラスタ(インスタンス)を識別する名前を設定します。 クラスタ名はこのクラスタのすべてのサーバプロセスのプロセス表題に表れます。 更に、スタンバイ接続のデフォルトのアプリケーション名となります。 (synchronous_standby_names参照。)

クラスタ名はNAMEDATALEN文字(標準のビルドでは64文字)より少ない文字列です。 表示可能なASCII文字だけがcluster_nameの値として設定できます。 他の文字は、疑問符(?)に置き換えられます。 空文字''(これがデフォルト値です)が設定されると、クラスタ名は表示されません。 このパラメータはサーバ起動時にのみ設定できます。

update_process_title (boolean)

サーバが新しいSQLコマンドを受け取る時に毎回、プロセスタイトルを更新できるようにします。 この設定値はたいていのプラットフォームでonがデフォルトになっていますが、Windowsではプロセスタイトルを更新するオーバーヘッドが大きいため、offがデフォルトになっています。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。