Configuration parameters (GUCs)

これらのGrand Unified Configuration（GUC）構成パラメーターは、 EDB Postgres Extended Serverで利用できます。

バックエンドパラメーター

バックエンドパラメーターは、スリープまたはエラーをPostgreSQLと拡張機能に注入するためのテストプローブポイントインフラストラクチャを導入します。

Postgresコードコード全体で定義されたPROBE_POINT は、重要なコードパスをマークします。これらのプローブポイントは、現在のバックエンドに信号を送信するか、LOG /ERROR /FATAL /PANIC をelog(…)するためにアクティブ化される場合があります。また、または代わりに、コードのその時点で遅延を追加する場合があります。

明示的にアクティブ化されない限り、プローブポイントは効果がなく、オプティマイザーヒント付きの単一のブランチのみを追加するため、ホットパスで安全です。

アクティブなプローブポイントがヒットし、カウンターが満たされた場合、指定されたスリープ間隔の後、ログメッセージは常にDEBUG1 以上で出力されます。

pg2q.probe_point

2ndQPostgresのコード内、またはPROBE_POINT を定義する拡張機能内のPROBE_POINT の名前。このパラメーターは検証されていません。存在しないプローブポイントに名前が付けられた場合、ヒットすることはありません。

アクティブにできるプローブポイントは1つだけです。これはリストではありません。リストを提供しようとしても、一致するものはありません。

プローブポイントには通常、一意の名前が付けられます。これは、定義されているコード内のPROBE_POINT マクロへの引数として指定されます。複数のコードパスが目的の同じアクションをトリガーする場合、同じPROBE_POINT 名前を使用することもできます。いずれかのパスが取られると、プローブが起動します。

pg2q.probe_counter

このパラメーターで指定された回数ループが実行された後にのみ、プローブを操作する必要がある場合があります。このような場合、このGUCをプローブポイントが発砲する反復回数に設定し、カウンターをリセットします。

デフォルト値は1 で、名前が一致するとプローブポイントが常に起動することを意味します。

pg2q.probe_sleep

プローブポイントにヒットした後、 pg2q.probe_sleep ミリ秒スリープします。次に、 pg2q.probe_action でアクションを起動します。

pg2q.probe_action

名前付きpg2q.probe_point がヒットしたときに実行するアクション。使用可能なアクションは次のとおりです。

• sleep —プローブ名を指定してDEBUG メッセージを発行します。

• log —プローブ名を指定してLOG メッセージを発行します。

• error — elog(ERROR, ...) ERROR 条件を発生させます。

• fatal — elog(FATAL, ...) 。

• panic — elog(PANIC, ...) 、通常はabort() を呼び出し、 SIGABRT （信号6）を配信して、バックエンドをコアダンプします。プローブポイントは、ハードulimitが許可する場合、コアファイル制限を設定してコアダンプを有効にしようとします。

• sigint 、sigterm 、sigquit 、sigkill ：名前付き信号をプローブポイントにヒットしたバックエンドに配信します。

pg2q.probe_backend_pid

0以外の場合、このIDのバックエンド以外のバックエンドでは、プローブのスリープとアクションがスキップされます。

server_2q_version_num およびserver_2q_version

server_2q_version_num およびserver_2q_version 構成パラメーターを使用すると、それぞれ2ndQuadrant固有のバージョン番号とバージョン部分文字列に外部モジュールからアクセスできます。

テーブルレベルの圧縮制御オプション

テーブルレベルオプション compress_tuple_target を設定して、タプルの圧縮をトリガーするタイミングを決定できます。以前は、 toast_tuple_target （またはコンパイル時のデフォルト）を使用して、タプルを圧縮するかどうかを決定していました。ただし、これは、タプルが十分に大きく、優れた圧縮率を持っているが、トーストしきい値を超えるには十分大きくない場合に有害でした。

pg2q.max_tuple_field_size

テーブルに書き込むことができる1つのフィールドの内部表現の最大非圧縮サイズをバイト単位で制限します。

デフォルトのpg2q.max_tuple_field_size は1073740799バイトで、1GiB未満の1024バイトです。この値は、通常PostgreSQLによって課される1 GiBの最大フィールドサイズよりもわずかに小さいです。このマージンは、タプルがディスクにコミットされたが、論理デコード出力プラグインで処理してダウンストリームサーバーに送信できないケースを防ぐのに役立ちます。

pg2q.max_tuple_field_size を1GB または11073741823 に設定して、機能を無効にします。

アプリケーションが大きなフィールドの挿入に依存していない場合は、 pg2q.max_tuple_field_size を100MB以下など、はるかに小さな値に設定することを検討してください。とりわけ、大規模なフィールドは次のことができます。

• 驚くべきアプリケーションの動作を引き起こす

• クエリとレプリケーション中のデータベースエンジンのメモリ消費量を増やす

• 論理レプリケーションを遅くする

このパラメーターが有効になっている間、特大のフィールドにより、特大のフィールドをINSERT またはUPDATE するクエリが次のようなERROR で失敗します。

ERROR: field big_binary_field_name in row is larger than pg2q.max_tuple_field_size
DETAIL: New or updated row in relation some_table has field big_binary_field_name
    (attno=2) with size 8161 bytes which exceeds limit 1073740799B configured
    in pg2q.max_tuple_field_size
SQLSTATE: 53400 configuration_limit_exceeded

pg2q.max_tuple_field_size を設定できるのはスーパーユーザーだけです。非スーパーユーザーによる設定を許可する場合は、 SECURITY DEFINER 関数ラッパーを使用できます。

pg2q.max_tuple_field_size を変更した場合、すでにディスク上にある現在のpg2q.max_tuple_field_size より大きいフィールドは変更されません。いつものようにSELECT できます。更新操作によって作成された新しいタプルが現在アクティブなサイズ制限を満たさない限り、特大のフィールドが変更されなくても、特大のフィールドを持つタプルに影響を与えるUPDATE は失敗します。

DELETE 操作は、フィールドサイズの制限をチェックしません。

制限は、フィールドのI / Oのテキスト表現サイズに強制されません。そうすると、PostgreSQLが制限よりも大きな一時的なインメモリjsonオブジェクトを作成および処理できないためです。

この制限は、セットを返す関数、CTE、ビューなど、タプルストア内の一時的なタプルには適用されません。サイズチェックは、 MATERIALIZED VIEW に対しても意図的に強制されません。

警告

pg2q.max_tuple_field_size は`pg_restore` に適用されます。データベースに特大のタプルが含まれている場合、通常どおり`pg_dump` を実行します。ただし、後続の`pg_restore` は前述のエラーで失敗します。これをワークアラウンドするには、 PGOPTIONS または`options` 接続パラメーター文字列を使用して、接続オプションで`pg2q.max_tuple_field_size` をオーバーライドしてダンプを復元します。例：

PGOPTIONS=-c pg2q.max_tuple_field_size=11073741823 pg_restore ...

データ型の詳細：

• bytea フィールドの場合、使用されるサイズはデコードされたバイナリサイズです。これは、16進または8進のエスケープ形式のテキスト表現サイズ、つまりフィールドのoctet_length() ではありません。

bytea_output = 'hex' を想定すると、I / O表現の最大サイズは2 * pg2q.max_tuple_field_size + 2 バイトです。

• text 、json 、またはxml フィールドの場合、測定サイズは、文字数ではなく、現在のデータベースエンコーディング（フィールドのoctet_length() ）のテキストのバイト数です。 UTF-8エンコーディングでは、通常1文字は1バイトを消費しますが、言語やスクリプトによっては6バイト以上を消費する場合があります。

• jsonb フィールドの場合、測定サイズは、PostgreSQL内部のjsonbエンコードデータ型表現、jsonドキュメントのテキスト表現のサイズです。場合によっては、大きなjsonドキュメントのjsonb 表現がテキスト表現よりも小さくなります。これは、一般的ではありませんが、特定のpg2q.max_tuple_field_size より大きいテキスト表現を持つjsonドキュメントを挿入できることを意味します。

• 拡張定義データ型の動作は、データ型の実装に依存します。

この制限に使用されるフィールドサイズは、pg_column_size() 関数によって報告されるサイズから、ターゲットデータ型のリテラルで使用される場合、PostgreSQLが可変長データ型に追加するヘッダーの4バイトを引いたサイズです。例：

demo=> SELECT pg_column_size(BYTEA \x00010203040506070809) - 4;
14

たとえば、 jsonbフィールドの計算されたサイズを表示するには、次を使用します。

SELECT pg_column_size(JSONB {"my_json_document": "yes"}) - 4;

TOAST圧縮のため、pg_column_size() は既存のディスク上のフィールドで呼び出されたときにより小さい値を報告することがよくあります。また、ディスク上の短い値のヘッダーは、4バイトではなく1バイトになる場合があります。

pg2q.max_tuple_size

テーブルに書き込むことができる単一のタプルの最大サイズを制限します。この値は、潜在的に圧縮可能または外部ストレージ対応のすべてのフィールド値の非圧縮幅を含む合計行幅です。フィールドヘッダーはサイズに対してカウントされますが、固定行ヘッダーはカウントされません。

論理レプリケーションなどの多くのPostgreSQL操作は、多くのアプリケーションと同様に、行全体で機能します。この設定を使用して、アプリケーションにとって妥当と考える最大行サイズに制限を課し、操作上の問題を引き起こす可能性のある特大の行を誤って作成するのを防ぐことができます。

既存のタプルのUPDATE に適用すると、 pg2q.max_tuple_size はpg2q.max_tuple_field_size ほど厳密には強制されません。 PLAIN 以外のストレージを持つ列の変更されていない値のフルサイズはカウントしません。

警告

pg2q.max_tuple_size は`pg_restore` に適用されます。 pg2q.max_tuple_field_size の警告を参照してください。