Configuration parameters (GUCs) =============================== これらのGrand Unified ConfigurationGUC構成パラメーターは、 EDB Postgres Extended Serverで使用できます。 バックエンドパラメーター ------------------------ バックエンドパラメーターは、PostgreSQLおよび拡張機能にスリープまたはエラーを注入するためのテストプローブポイントインフラストラクチャを導入します。 Postgresコード全体で定義された\ ``PROBE_POINT`` は、重要なコードパスをマークします。これらのプローブポイントは、現在のバックエンドに通知するか、elog(…) ``LOG`` /``ERROR`` /``FATAL`` /``PANIC`` に信号を送信するためにアクティブになる場合があります。また、またはその代わりに、コードのその時点で遅延を追加する場合があります。 明示的にアクティブ化しない限り、プローブポイントは効果がなく、単一のオプティマイザーヒント付きブランチを追加するだけであるため、ホットパスでは安全です。 アクティブなプローブポイントがヒットし、カウンターが満たされると、指定されたスリープ間隔の後、ログメッセージは常に\ ``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 ^^^^^^^^^^^^^^^^^^^^^^ ゼロ以外の場合、プローブのスリープとアクションは、このIDのバックエンド以外のバックエンドでスキップされます。 server_2q_version_numおよびserver_2q_version -------------------------------------------- ``server_2q_version_num`` および\ ``server_2q_version`` 構成パラメーターを使用すると、外部モジュールからそれぞれ2ndQuadrant固有のバージョン番号とバージョンサブ文字列にアクセスできます。 テーブルレベルの圧縮制御オプション ---------------------------------- テーブルレベルオプション ``compress_tuple_target`` を設定して、タプルの圧縮をトリガーするタイミングを決定できます。以前は、 ``toast_tuple_target`` またはコンパイル時のデフォルトを使用して、タプルを圧縮するかどうかを決定しました。ただし、これは、タプルが十分に大きく、優れた圧縮率を持っているが、トーストのしきい値を超えるほど十分に大きくない場合、有害でした。 .. raw:: html ``pg2q.max_tuple_field_size`` ----------------------------- テーブルに書き込むことができるフィールドの内部表現の最大非圧縮サイズをバイト単位で制限します。 デフォルトの\ ``pg2q.max_tuple_field_size`` は1073740799バイトで、これは1 GiB未満の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`` にも意図的に適用されません。 .. WARNING:: `pg_restore` には`pg2q.max_tuple_field_size` が適用されます。データベースに大きすぎるタプルが含まれている場合、通常のように`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`` 以外のストレージを使用する列の未変更の値のフルサイズはカウントしません。 .. WARNING:: `pg_restore` には`pg2q.max_tuple_size` が適用されます。 `pg2q.max_tuple_field_size` の注意事項を参照してください。