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 またはコンパイル時のデフォルトを使用して、タプルを圧縮するかどうかを決定しました。ただし、これは、タプルが十分に大きく、優れた圧縮率を持っているが、トーストのしきい値を超えるほど十分に大きくない場合、有害でした。

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 にも意図的に適用されません。

警告

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 以外のストレージを使用する列の未変更の値のフルサイズはカウントしません。

警告

pg_restore には`pg2q.max_tuple_size` が適用されます。 pg2q.max_tuple_field_size の注意事項を参照してください。